Re: How to set "isremote" ?

[Jacob Bachmeyer]

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