This patch mentions that the problem seems to be specific to certain
target architectures and possibly certain testing sites.
Would this be better solved by setting timeouts in a site or board
configuration file?
I recognize that the remote_exec procedure is not currently sensitive to
that either, so there will be an enhancement here for 1.6.4 either way.
I will say now that the DEJAGNU_TIMEOUT environment variable will *not*
be accepted upstream because there are many different timeouts in
various parts of DejaGnu and providing only a single "knob" to adjust
all of them is not appropriate. If there are other components in Debian
that will need to be updated, I recommend changing the environment
variable used to DEJAGNU_REMOTE_EXEC_TIMEOUT as an interim measure as
soon as possible. That name is acceptable for this purpose, although
the possibility of instead setting a target configuration parameter is
likely to be preferred. There is also little difficulty in allowing an
environment variable to override a target configuration parameter, for
ease of development.
Also, does this need to be an environment variable or can it be a
variable passed on the runtest command line? (What is the surrounding
context here?) The latter would be preferred if feasible simply to
reduce clutter in the environment:
[...]
+ } elsif { [info exists DEJAGNU_REMOTE_EXEC_TIMEOUT] } {
+ set timeout $DEJAGNU_REMOTE_EXEC_TIMEOUT
[...]
and add "DEJAGNU_REMOTE_EXEC_TIMEOUT=600" to the runtest command line.
Such variables are set early in runtest.exp while parsing the command
line but are distinct from the environment.
Backporting patches for this to 1.6.2 and 1.6.3 for Debian should be
fairly easy once they land on Git master for 1.6.4.
-- Jacob
_______________________________________________
Bug-dejagnu mailing list
Bug-dejagnu@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-dejagnu
