Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

The three of us had an IRL conversation.  Here is what I think we
agreed:

* We intend to make the XTF runner capable of reading
  xenconsoled-created logfiles.  Both XenRT and osstest configure
  xenconsoled appropriately.

  The xtf runner will need to

     - on each test, wait for the test domain to shutdown, and then

     - look backwards through the xenconsoled logfile for the
       indication that the domain started (eg, a banner printed by the
       domain, or message from xenconsoled), and parse the relevant
       output there.  (This is needed because starting the same-named
       domain multiple times results in concatenations of the console
       output in the xenconsoled guest output logfile.)

     - arrange for the guest to be preserved on crash (at least)
       so that if the domain crashed, we don't risk parsing the
       output from a previous run.  Instead we can see it having
       crashed and report that as a failure.

* We intend to make `xl create -c' work to find all of the output,
  by (i) starting the domain paused (ii) spawning xenconsoled
  (iii) awaiting a new startup indication from xenconsoled
  (iv) unpausing the domain.  This will be done in xen-unstable.

  I propose the following startup protocol: xl runs
     xenconsole --startup-notify-fd=FD
  where FD is the writing end of a pipe.  xl waits for xenconsole to
  write the byte 0x00 to the FD.  If xenconsoled crashes, xl can tell
  by the EOF on the pipe.  (This approach saves xl from having to try
  to wait for either SIGCHLD or fd readability.)

  (The systemd startup notification protocol is too complex to
  reimplement and would therefore introduce a dependency on
  libsystemd's sd_notify, which would be awkward.  There is also the
  upstart SIGSTOP protocol but it could interact badly with an
  interactive user who uses ^Z.)

  The xtf runner would also be able to use `xl create -c' and simply
  expect to see all the console output.

  (We also discussed making xenconsole print something to its stdout
  or stderr when it has successfully connected, and when it
  disconnects.  While we're editing xenconsole it would probably be
  nice to do this, but with our plans it's not needed for XTF.)

As a result, the xtf runner can be used with a default install of
xen-unstable.  For older versions of Xen it will be necessary to
reconfigure xenconsoled, if the user wants to get reliable pass/fail
reports from the xtf runner.

* We discussed changing xenconsoled to not tear down the guest console
  until the guest is destroyed, rather than already tearing it down
  when the guest is shut down.  This is not now needed for the above,
  but I still think it would be nice.  However it is done, it should
  arrange that `xl console' doesn't hang waiting for further output
  from a crashed or shutdown domain (but perhaps should wait for
  output from a rebooting domain?).  It would probably be a good idea
  to put this work item in a bucket with `overhaul the console stuff'.

Ian.

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