From: Wei Liu <wei.liu2@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Wei Liu <wei.liu2@citrix.com>,
Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
Date: Mon, 15 Aug 2016 11:58:39 +0100 [thread overview]
Message-ID: <20160815105839.GP20641@citrix.com> (raw)
In-Reply-To: <22445.39977.614332.762687@mariner.uk.xensource.com>
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 ?
>
> 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).
>
It's only empirical, but my experience of running this patch in logfile
mode (a few dozen times) hasn't seen a single error due to missing output.
I can go for the polling mode but with a timeout of 1 second. A bit
hacky, but hopefully should work good enough.
I want to get something working which I can run in osstest. We can go
with something more sophisticated if the above scheme is deemed not
suitable for osstest.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
prev parent reply other threads:[~2016-08-15 10:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-11 14:14 [XTF PATCH v2] xtf-runner: support two modes for getting output Wei Liu
2016-08-11 16:27 ` Ian Jackson
2016-08-11 16:50 ` Wei Liu
2016-08-11 17:17 ` Ian Jackson
2016-08-11 17:21 ` Andrew Cooper
2016-08-11 17:23 ` Wei Liu
2016-08-11 17:51 ` Wei Liu
2016-08-11 17:54 ` Andrew Cooper
2016-08-11 18:29 ` Ian Jackson
2016-08-12 9:23 ` Wei Liu
2016-08-12 9:51 ` Ian Jackson
2016-08-12 13:28 ` Wei Liu
2016-08-15 10:58 ` Wei Liu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160815105839.GP20641@citrix.com \
--to=wei.liu2@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).