From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Jan-Simon =?ISO-8859-1?Q?M=F6ller?= Date: Thu, 02 Feb 2017 11:04:33 +0100 Message-ID: <3704428.AOdDsIb3nH@elrond> In-Reply-To: References: <000d01d26ba1$94c8a5d0$be59f170$@toshiba.co.jp> <2787487.KsR9eGO5q9@elrond> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [Fuego] Fuego's version up and other changes List-Id: Mailing list for the Fuego test framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Bird, Timothy" Cc: "fuego@lists.linuxfoundation.org" 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 h= ere as > > this call must block until the board is up. >=20 > After thinking about this, I believe that link setup and teardown sho= uld > 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) operatio= ns > 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 transpo= rt=20 (e.g. on first cmd/get/put) - I've no knowledge about the job and how l= ong it=20 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 ses= sion=20 is. So just in the transport layer is not enough for this type of integrati= on. Currently I'm using the "ssh" transport. The job setup/teardown is done= =20 pre/post the test job. >=20 > 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 a= ny=20 knowledge about the session right now. There might also be the question if we pool multiple tests and run them= in one=20 setup/teardown instead of doing the setup/teardown for _each_ test=20 individually. So there might also be the need for a "keepalive" flag or= =20 counter. > > In this case our predifined timeouts are bogus as they track not ju= st the > > test run, but all processing. >=20 > Agreed. In general the timeouts need some better definition, as diff= erent > tests and different transports (and different boards) will need diffe= rent > timeouts. We need to calculate them for each of the identified phases (setup, bui= ld,=20 deploy, run, ...) Best, --=20 -- Jan-Simon M=F6ller dl9pf@gmx.de