|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3.2] libxl: Design of an async API to issue QMP commands to QEMU [and 1 more messages]
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...
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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |