[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 01/15] libxl: Design of an async API to issue QMP commands to QEMU
On Fri, Sep 07, 2018 at 04:10:50PM +0100, Anthony PERARD wrote: > All the functions will be implemented in later patches. > > This patch includes the API that libxl can use to send QMP commands to > QEMU. > > Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx> > --- > > Notes: > v5: > some changes in the comment > > tools/libxl/libxl_internal.h | 72 +++++++++++++++++++++++++++++++++++- > 1 file changed, 70 insertions(+), 2 deletions(-) > > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index 802382c704..979a9947f0 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -202,6 +202,8 @@ typedef struct libxl__ao libxl__ao; > typedef struct libxl__aop_occurred libxl__aop_occurred; > typedef struct libxl__osevent_hook_nexus libxl__osevent_hook_nexus; > typedef struct libxl__osevent_hook_nexi libxl__osevent_hook_nexi; > +typedef struct libxl__json_object libxl__json_object; > +typedef struct libxl__carefd libxl__carefd; > > typedef struct libxl__domain_create_state libxl__domain_create_state; > typedef void libxl__domain_create_cb(struct libxl__egc *egc, > @@ -357,6 +359,72 @@ struct libxl__ev_child { > LIBXL_LIST_ENTRY(struct libxl__ev_child) entry; > }; > > +/* > + * QMP asynchronous calls > + * > + * This facility allows a command to be sent to QEMU, and the response to be > + * handed to a callback function. > + * > + * Commands can be chained, with a same connection. (e.g. "add-fd" will need > to > + * be chained to the next command). A libxl__ev_qmp can be reused when the > + * callback is been called in order to use the same connection. > + * > + * Only one connection at a time can be made to one QEMU, so avoid keeping a > + * libxl__ev_qmp Connected for to long and call libxl__ev_qmp_dispose as soon > + * as it is not needed anymore. From where this limitation comes? Was that true before? I ask, because that limitation would ease Linux-based stubdomain case, where QMP over console have indeed only a single channel. > + * > + * Possible states of a libxl__ev_qmp: > + * Undefined > + * Might contain anything. > + * Idle > + * Struct contents are defined enough to pass to any libxl__ev_qmp_* > + * function. > + * 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. > + * Connected > + * Struct contain allocated ressources. > + * Calling _send() with this same ev will use the same QMP connection. > + * _dispose() must be called to reclaim resources. > + * > + * libxl__ev_qmp_init: Undefined/Idle -> Idle > + * > + * libxl__ev_qmp_send: Idle/Connected -> Active (on error: Idle) Does it also mean libxl__ev_qmp_init or libxl__ev_qmp_send should deal with connecting to qemu, which _does not know it is a new connection_, so will not send a greeting etc? In case of QMP over console, there is no OOB method to signal open/close (at least not easily). I implemented rather hacky/incomplete way to reset QMP connection - or rather - send greeting again, but that may result in confusing situations, like QEMU sending response to previous command to unsuspecting new libxl client. > + * Sends a command to QEMU. > + * callback will be called when a response is received or when an error > + * as occured. > + * > + * libxl__ev_qmp_dispose: Connected/Active/Idle -> Idle > + * > + * callback: When called: Active -> Connected > + * When called, ev is Connected and can be reused or disposed of. > + * If an error occured, it is called with response == NULL and the error > + * code in rc. > + * The callback is only called once. > + */ -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |