[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



On Mon, Jul 16, 2018 at 04:28:00PM +0100, Anthony PERARD wrote:
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 760f2798c7..1e6fbb64a5 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -1237,6 +1237,108 @@ int libxl__qmp_initializations(libxl__gc *gc, 
> uint32_t domid,
>      return ret;
>  }
>  
> +/* ------------ Implementation of asynchronous QMP calls ------------ */
> +
> +/*
> + * 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 are different state possible in which the client can be in, with the
> + * list of possible transition listed after.
> + *
> + * States:
> + *   Disconnected
> + *      Nothing, no allocated ressources.
> + *   Connecting
> + *      Have allocated ressources, including a connection to a QMP socket.
> + *      Waiting for server greeting.
> + *   Capability Negociation
> + *      QMP server is in Capabilities Negotiation mode.
> + *      Waiting for a response to the "qmp_capabilities" command.
> + *   Connected
> + *      QMP server is in command mode, commands can be issued.
> + *      There is outstanding command to be sent and/or there are in-flight
> + *      libxl_ev_qmp with callback.
> + *   Within A Callback
> + *      The QMP client enter this state when a callback is called.
> + *      The connection to QEMU is kept open until at least the callback
> + *      return.
> + *
> + * Here is the transition from one state to the next:
> + *    Disconnected -> Connecting
> + *      Connect to the QMP socket.
> + *    Connecting -> Capability Negociation
> + *      Server greeting received
> + *      Send "qmp_capabilities"
> + *    Capability Negociation -> Connected
> + *      Response to "qmp_capabilities" received"
> + *
> + *    Connected -> Within A Callback
> + *      When a response is received, if there's a callback associated to it,
> + *      it is called.
> + *    Connected -> Disconnected
> + *      When both list of in-flight event and command to send are empty.
> + *
> + *    Within A Callback -> Connected
> + *      On return from a libxl__ev_qmp callback, there are more command to 
> send
> + *      or there are other in-flight event.
> + *    Within A Callback -> Disconnected
> + *      On return from a libxl__ev_qmp callback, both list of command to send
> + *      and list of in-flight event are empty.
> + *      QMP socket connection is closed, all ressources are deallocated.
> + *
> + *   * -> Disconnected
> + *      Whenever a error occure with the QMP socket, all outstanding callback
> + *      will be called with an error, all ressource will be deallocated.
> + *
> + *
> + * checkout qemu.git:docs/interop/qmp-spec.txt for more information on the
> + * qmp protocol.
> + */
> +
> +typedef enum qmp_states {
> +    qmp_state_disconnected = 1,
> +    qmp_state_connecting,
> +    qmp_state_capability_negociation,
> +    qmp_state_connected,
> +    qmp_state_within_callback,
> +} qmp_states;
> +
> +typedef struct qmp_tx_buf qmp_tx_buf;
> +struct qmp_tx_buf {
> +    char *buf;
> +    size_t len;
> +    /* File descriptor to send along the command */
> +    libxl__carefd *efd;
> +    LIBXL_TAILQ_ENTRY(qmp_tx_buf) entry;
> +};
> +
> +struct qmp_state {
> +    libxl__carefd *cfd;
> +    libxl__ev_fd efd;
> +    uint32_t domid;
> +
> +    /* Current state */
> +    qmp_states state;


-- 
Anthony PERARD

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

 


Rackspace

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