Re: [PATCH v3.2] libxl: Design of an async API to issue QMP commands to QEMU [and 1 more messages]

[Anthony PERARD <anthony.perard@citrix.com>]

On Mon, Jul 16, 2018 at 06:04:30PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v3.2] libxl: Design of an async API to issue QMP commands to QEMU"):
> > All the functions will be implemented in later patches.
> > 
> > This patch includes the API that libxl can use to send QMP commands to
> > QEMU.
> ...
> > + * This facility allows a command to be sent to QEMU, and the response to be
> > + * handed to a callback function.  Each libxl__ev_qmp handles zero or one
> > + * outstanding command; if multiple commands are to be sent concurrently,
> > + * multiple libxl__ev_qmp's must be used.
> > + *
> > + * Possible states:
> > + *  Undefined
> > + *    Might contain anything.
> > + *  Idle
> > + *    Struct contents are defined enough to pass to any libxl__ev_qmp_*
> > + *    functions.
> > + *    The struct does not contain references to any allocated private resources
> > + *    so can be thrown away.
> > + *  Active
> > + *    Currently waiting for the callback to be called.
> > + *    _dispose must be called to reclaim resources (or wait for the callback to
> > + *    be called).
> > + *
> > + * libxl__ev_qmp_init: Undefined/Idle -> Idle
> > + *
> > + * libxl__ev_qmp_send: Idle -> Active (on error: Idle)
> > + *    Sends a command to QEMU.
> > + *
> > + * libxl__ev_qmp_dispose: Active/Idle -> Idle
> > + *
> > + * callback:
> > + *    When called, ev is Idle, so can be reused or thrown away.
> > + *    When an error occured, it is called with response == NULL and the error
> > + *    code in rc.
> 
> You have removed this text:
> 
>   + * When called from within a callback, the same QMP connection will be
>   + * reused to execute the new command. This is important in the case
>   + * where the first command is "add-fd" and the second command use the
>   + * fdset created by QEMU.
> 
> That removes the need for a fourth state, as I discussed earlier.  But
> does this not introduce the problem that this text was addressing: Ie
> there is no way for the user of libxl_ev_qmp to ensure that the
> commands to add-fd, and use the fdset, occur on the same qmp
> connection.
> 
> What has changed since you wrote that ?  Or have I misunderstood
> something ?
> 
> NB that I haven't yet read in detail the part about describing the
> implementation, ie the qmp_state but I think this problem exists no
> matter what that implementation looks like...

Please do read the implementation description, it should explain why
there is no fourth state.

Thanks.

> Anthony PERARD writes ("Re: [PATCH v3.2] libxl: Design of an async API to issue QMP commands to QEMU"):
> > On Mon, Jul 16, 2018 at 04:28:00PM +0100, Anthony PERARD wrote:
> > > + * Implementation of the QMP client.
> > > + *
> > 
> > Here, I wanted to add more description, but forgot to commit before to
> > sent the patch, it should read:
> > 
> > + * This struct qmp_state is used by the libxl__ev_qmp_* functions, but it is
> > + * not visible to users of libxl__ev_qmp_*. It is allocated as needed and
> > + * stored in CTX in order to allow reuse of a same QMP connection between
> > + * different users.
> 
> This makes sense, thanks.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel