Re: [Xen-devel] [XTF PATCH v2] xtf-runner: support two modes for getting output

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting 
output"):
> On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote:
> > We don't care when xenconsoled closes the logfile.  We care about when
> > it last calls write() (with a nonempty buffer).
> 
> In logfile mode, no console client is spawned, because it is not
> reliable -- that's why we use logfile mode in the first place.
> 
> And I would rather just add a bodge (wait 1 or 2 seconds)

That would increase the duration of each test by that 1 or 2 seconds.
I suppose you could conclude the logfile is complete if it contains
the expected end-of-run message from the vm, and only poll if not.

But, it's worse:

I went to read the xenconsoled source code, and it can handle a domain
death event before finishing reading all of the data out of a domain's
ring.

Maybe this will be mitigated by XTF's printf waiting for the
xenconsoled ring pointer to catch up ?

xenconsoled advances the ring pointer before writing to the logfile,
but (assuming there's no overflow), the write will happen before it
goes back into the event loop, so it won't be lost.

> than to rely on sophisticated hack.

To my mind polling the logfile looking for the final message from the
vm is something of a hack.

But indeed I can't see another way to wait for xenconsoled, than
going behind libxl's back with something like
 * spawn xl create -p -F
 * look for the console tty in xenstore
 * open the console tty
 * unpause
 * wait for the console tty to get eof

This is not a logfile mode at all, of course.  It probably wouldn't be
easily adaptable to other toolstacks (eg XenServer).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel