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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 7 Jun 2011, Anthony PERARD wrote:
> On Tue, Jun 7, 2011 at 09:58, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > 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).
> 
> Ok, I will change that.
> 
> > 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.
> 
> Actually, QEMU doesn't seem to handle more than one client at a time
> with a single socket. For more client, we can always open more than
> one QMP server with different path/port. In this case, they will be
> handle separately by QEMU.
> 
> To handle the async request, it's relatively easy. When we send a
> command, we can add an "id" to this request and the id will be part of
> the answer. I use that to handle the replies.
> 
> For the QEMU event/async notification, indeed, all clients receive them.
 
That means that if we provide a single QMP server socket we cannot
expose QMP to xl at all, because we have to keep the server socket free
for libxl to use whenever the library sees fit.

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