Re: [Xen-devel] [PATCH 01/35] libxl: Make libxl_domain_unpause async

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Tue, Sep 17, 2019 at 05:50:05PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH 01/35] libxl: Make libxl_domain_unpause 
> async"):
> > libxl_domain_unpause needs to make QMP calls, which are asynchronous,
> > change the API to reflect that.
> > 
> > Do the same with libxl_domain_pause async, even if it will keep
> > completing synchronously.
> 
> Jolly good.  I think, though, that there should be a HAVE_...  for
> this set of API changes.  I don't mind if it goes into the last patch

I thought that HAVE_* wasn't needed when the API version is bumped. But
now I guess that the HAVE_* macro are the only way for an application
to build against old version of libxl since the version number isn't
exposed.

The question is, how many macro should there be? As many macro as there
are function changed? Or just one?

For many, I can add that:
    /*
     * LIBXL_HAVE_*_ASYNC
     *
     * Those defines indicates that the function libxl_*()'s API has changed
     * and have an extra parameter "ao_how" which means that the function can be
     * executed asynchronously. Those functions are:
     *   libxl_domain_pause()
     *   libxl_domain_unpause()
     *   libxl_send_trigger()
     *   libxl_set_vcpuonline()
     *   libxl_retrieve_domain_configuration()
     *   libxl_qemu_monitor_command()
     */
    #define LIBXL_HAVE_DOMAIN_PAUSE_ASYNC 1
    #define LIBXL_HAVE_DOMAIN_UNPAUSE_ASYNC 1
    #define LIBXL_HAVE_SEND_TRIGGER_ASYNC 1
    #define LIBXL_HAVE_SET_VCPUONLINE_ASYNC 1
    #define LIBXL_HAVE_RETRIEVE_DOMAIN_CONFIGURATION_ASYNC 1
    #define LIBXL_HAVE_QEMU_MONITOR_COMMAND_ASYNC 1

If only one, I don't know how to call it, maybe on of or related:
    LIBXL_HAVE_QMP_FN_ASYNC
    LIBXL_HAVE_FN_USING_QMP_ASYNC
with the same comment listing all affected functions.

> or the first one.  Assuming you add that to the series in v2:
> 
> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

Thanks,

-- 
Anthony PERARD

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