[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 14/31] libxl_qmp_ev: Introduce libxl__ev_qmp_start() to connect to QMP

Anthony PERARD writes ("[PATCH v3 14/31] libxl_qmp_ev: Introduce 
libxl__ev_qmp_start() to connect to QMP"):
> This is a first patch to implement libxl__ev_qmp, it only connect to the
> QMP socket of QEMU and register a callback that does nothing.
> @@ -503,6 +504,9 @@ struct libxl__ctx {
>      LIBXL_LIST_ENTRY(libxl_ctx) sigchld_users_entry;
>      libxl_version_info version_info;
> +
> +    // FIXME: May need a list, with on state for each domid
> +    libxl__ev_qmp_state *qmp_ev;

My thought is that the lifetime of this thing should probably be in
each relevant ao.

Is it too inconvenient to reconnect to qmp for every libxl operation ?
If it is then this needs to be a cache, a bit like libxl__poller but
different.  But that can be handled inside what you are calling

Also, I think if you are going to have a libxl__ev_qmp it needs to be
just like all the other libxl__ev_ things.  It's not clear to me that
QMP is similar enough.

Do you actually need an explicit "start" or "connect" operation ?
I think in any case the "send a qmp command" operations should
probably connect automatically.

So something like this:

   /* libxl__qmp_state has the following states:
    *   Undefined
    *   Disconnected
    *   Connected

   void libxl__qmp_init(ibxl__qmp_state *qmp); /* U -> D */

   int libxl__qmp_connect(libxl__gc *gc, uint32_t domid,
                          libxl__qmp_state *qmp_upd); /* [UC] -> C */

   int libxl__qmp_dispose(libxl__qmp_state *qmp_upd); /* [DC] -> D */

   int libxl__qmp_command( lots of parameters incl callback ); /* [DC] */

> +_hidden libxl__ev_qmp_state *libxl__ev_qmp_start(libxl__gc *gc, uint32_t 
> domid);

Line length.

Also, this interface does not support returning a proper error status.

> +libxl__ev_qmp_state *libxl__ev_qmp_start(libxl__gc *gc, uint32_t domid)
> +{
> +    int rc, r;
> +    struct sockaddr_un un;
> +    const char *qmp_socket_path;
> +    libxl__ev_qmp_state *qmp;
> +out:
> +    if (rc)
> +        libxl__ev_qmp_stop(gc, qmp);
> +    CTX_UNLOCK;
> +    return qmp;

I think the error handling is messed up here.  If this fails, you will
stop the qmp and then return it anyway.


Xen-devel mailing list



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