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

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

  • To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
  • From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Date: Tue, 7 Jun 2011 12:49:22 +0100
  • Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
  • Delivery-date: Tue, 07 Jun 2011 04:51:07 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=VPWuDO7UcO5+/CaaF6hGjjq6zAH6D71ro8wDcrPVDWE3mILiS7GNTRimgp6OAhc7Dl QLBK3MI+NG777sn3nNxGAblW7n1Rhm74/N0sT9Jr5fQK1soK84lqAz14I5JLo87obrwr ilU7ygenKNst7lNAnSw7LAw0PQpKmw2+MIx1Y=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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.

Anthony PERARD

Xen-devel mailing list



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