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

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel