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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Aug 12, 2016 at 10:51:37AM +0100, Ian Jackson wrote:
> 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 ?
> 

I think so.

Under normal circumstance (micro VM doesn't crash), we're sure that all
output is consumed by xenconsoled before the VM shuts down itself.

> 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.
> 

Correct.

> > 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).
> 

Andrew, what is your opinion?

Wei.

> Ian.

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