[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to set "isremote" ?

From: Jacob Bachmeyer
Subject: Re: How to set "isremote" ?
Date: Tue, 04 Jun 2019 18:12:27 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

Christophe Lyon wrote:
I've been debugging a problem where we clear "isremote" with:
unset_board_info isremote
set_board_info isremote 0
but this isn't taken into account correctly by is_remote (in
framework.exp), when we use target variants, because is_remote removes
the target variant specifications.

For instance, if we use --target-board=qemu, everything works well,
but if we use --target-board=qemu/-mcpu=XXX, then:
unset_board_info isremote
set_board_info isremote 0
clear the "isremote" flag for board=="qemu/-mcpu=XXX", but subsequent
calls to is_remote actually check the isremote flagfor board=="qemu"
(after removing the part after the "/")

Is that a bug in is_remote, or is there a clean way of setting "isremote"?

I am still unsure about exactly what a "board" is supposed to be in DejaGnu (perhaps someone else can clarify) but I suspect that you may be misunderstanding the variant feature. As far as I can tell, a "board" is supposed to be a physical device with some kind of hard-wired or network connection to the machine running DejaGnu, or a virtual device that behaves similarly. As such, *all* QEMU system emulator targets are "remote" in this sense -- isremote is set if the target is *not* localhost. A simulator running on localhost is *not* localhost -- it is a separate (virtual) machine. (For QEMU, things get interesting when you consider its user mode emulation feature, which is *not* remote in the sense that DejaGnu uses, but *does* require special handling to run programs, unless binfmt_misc is being used to test something else using an installed QEMU.) For similar reasons, the "unix" board is special and magic in various places -- "unix" *is* localhost in DejaGnu.

I have been working around default_target_compile lately (just finished the local-compile tests; although the tests are verifying the currently-known-broken Ada support, the goal is to have solid regression tests to enable rewriting default_target_compile to more explicitly express the flag-ordering constraints it follows so that the broken Ada support can be cleanly fixed instead of further tangling the "spaghetti") and it seems to me that the actual criteria for a "remote" board is that files must be explicitly transferred between the machine running DejaGnu and the remote target. There is also different handling for executing programs on a remote board: on localhost, programs are run using Expect's "spawn" command, while on remote boards, programs are run by using Expect to interact with a remote shell. A single-system-image cluster (as I understand that HURD is supposed to eventually support) makes this all kinds of "fun" to explain, because "localhost" will not always be local anymore!

There also seems to be an abstraction layer for particular targets to override normal remote handling -- QEMU may need that, depending on what you are testing. (In theory, you could use DejaGnu and QEMU to test Linux kernels if you override certain procedures.)

-- Jacob

reply via email to

[Prev in Thread] Current Thread [Next in Thread]