[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.