[Fuego] Fuego's version up and other changes

[Jan-Simon Möller]

Am Donnerstag, 2. Februar 2017, 01:35:58 schrieb Bird, Timothy:
> > - If a model like the "TARGET_SETUP_LINK" is used, we add a delay here as
> > this call must block until the board is up.
> 
> After thinking about this, I believe that link setup and teardown should
> be built into the transport layer, with the possibility of defining
> board-specific override functions.  I've been working on the serial
> transport feature, and it has some (possibly time-consuming) operations
> that are needed
> on the first interaction with the target, and not afterwards (during
> every put, get or cmd).

Agree, but there is a catch: if I put the lava-support into the transport 
(e.g. on first cmd/get/put) - I've no knowledge about the job and how long it 
might take and we'd have to add some state or timeout in the background to
release the connection as we don't know what the last "cmd" for the session 
is.
So just in the transport layer is not enough for this type of integration.

Currently I'm using the "ssh" transport. The job setup/teardown is done 
pre/post the test job.

> 
> I haven't seen your lava integration slides yet, but it sounds like
> they have some elaborate setup and teardown operations as well.

Still hacking, I'll send them on friday but don't expect miracles.

> Functionally, doing it in the transport layer would work the same,
> but just be placed in the base-board.fuegoclass file, with stubs for
> transports that don't require it.  e.g. ov_transport_setup() and
> ov_transport_teardown()

Ok, that is a possibility, but see my previous comment. We don't have any 
knowledge about the session right now.

There might also be the question if we pool multiple tests and run them in one 
setup/teardown instead of doing the setup/teardown for _each_ test 
individually. So there might also be the need for a "keepalive" flag or 
counter.

> > In this case our predifined timeouts are bogus as they track not just the
> > test run, but all processing.
> 
> Agreed.  In general the timeouts need some better definition, as different
> tests and different transports (and different boards) will need different
> timeouts.

We need to calculate them for each of the identified phases (setup, build, 
deploy, run, ...)

Best,

-- 
--
Jan-Simon Möller
dl9pf at gmx.de