Re: [Xen-devel] [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain.

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for 
qemu-xen runnning in a Linux-based stubdomain."):
> Doing it in this order would be susceptible to a race condition -
> server appearing after libxenvchan_client_init check, but before libxl
> register the watch.

I see the race you mean but happily xenstore already has a general
mechanism for avoiding it: after setting up a watch, it always fires
once immediately.  (Obviously we could have done the equivalent thing
open-coded in the caller of my proposed new init function variant.)

> Also, right now libxenvchan_client_init have only
> one possible error code: NULL (instead of struct libxenvchan *). Adding
> more elaborate error reporting would require API change.

I think libxenvchan_client_init sets errno.  All of the functions it
calls do so, so the errno value is passed through.  So we would just
need to reserve a specific errno value for this.

> As the xs path is provided by libxenvchan_client_init caller anyway,
> libxl can register watch before calling libxenvchan_client_init and wait
> on it

Yes.  (Sorry I didn't see that parameter yesterday.  I was really
being quite dim.)

Although because of the xswatch behaviour I describe above, libxl can
simply set up the watch unconditionally, and call
libxenvchan_client_init in the xswatch event handler function.

> if libxenvchan_client_init fails.

I'm not a fan of this.  I tend to be quite picky about error
handling.  I think we should define a specific errno value for `server
not set up'.  ENOENT is what it currently returns, so if we use that
we won't break existing clients.

As belt and braces we should probably have libxenvchan_client_init
turn any ENOENT other than from the xs_read of ring-ref into EIO with
a log error message.

I worked up a patch to do that, which I will post in a moment.  It
turned into a series...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel