[Xen-devel] Re: [PATCH] libxl, Introduce a QMP client

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Mon, 2011-06-06 at 19:31 +0100, Stefano Stabellini wrote:
> On Mon, 6 Jun 2011, Ian Campbell wrote:
> > I think we should try where possible to keep this stuff entirely within
> > libxl. The existing libxl event API is a bit of a mess but I think if it
> > were cleaned up (IanJ has a plan I think) then it would be the right
> > place to integrate the libxl and caller event loops.
> > 
> > For the time being though I think libxl should provide the fd and not
> > expect the caller to construct the path and open it etc. IOW
> > libxl_qmp_initialize should not take a socket option, it should
> > construct the path, do the open internally and return the fd.
> 
> I agree on this.
> 
> Libxl needs to use QMP internally for things like the serial. Libxl
> cannot rely on the caller (xl) to select on the fd and call
> libxl_qmp_do_next later for libxl to put the appropriate serial device
> on xenstore.
> Ideally QMP should be completely hidden inside libxl.
> 
> I think all the initialization details should be handled internally by
> libxl_domain_create_new, including opening the QMP connection and
> reading back the serial device.

Yes I think it would be better to have libxl open a short lived QMP
channel for specific operations entirely internally (including closing
it again).

If we don't do this then we need to be mindful of multithreaded users of
the library multiplexing over a single channel and all the inherent
complexity of matching replies to requests, blocking the caller threads,
handling async notifications while a request is in progress etc etc.

Probably we will also need a long-running channel dedicated to feeding
out into the user's event loop to handle async notifications etc.

How does QMP handle the async notifications with multiple connected
clients? I suppose they must all see them (or else writing a client
would be virtually impossible), in which case the function-specific
connections can simply discard them.

> After that libxl should probably expose a single event driven mechanism,
> both for xenstore and QMP, with some opaque callbacks in the QMP case.
> However this could be done together with the libxl events refactoring
> that Ian wants to do.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel