|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 07/10] libxl: make libxl_cd_insert "eject" + "insert"
On Thu, 2014-07-10 at 15:32 +0100, Wei Liu wrote:
> A "cdrom insert" is always processed as "eject" + "insert", with JSON
> config updated in between. So that we can know the correct state of
> CDROM later when we try to retrieve domain configuration: if xenstore is
> "empty", then CDROM is "empty"; otherwise use the information presented
> in JSON.
>
> Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
> ---
> tools/libxl/libxl.c | 48
> ++++++++++++++++++++++++++++++++++++++++--
> tools/libxl/libxl_internal.h | 34 ++++++++++++++++++++++++++++++
> 2 files changed, 80 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 58f07d2..69d94b1 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -2654,8 +2654,9 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t
> domid,
> return 0;
> }
>
> -int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk
> *disk,
> - const libxl_asyncop_how *ao_how)
> +static int libxl__cdrom_insert(libxl_ctx *ctx, uint32_t domid,
> + libxl_device_disk *disk,
> + const libxl_asyncop_how *ao_how)
> {
> AO_CREATE(ctx, domid, ao_how);
> int num = 0, i;
> @@ -2766,6 +2767,49 @@ out:
> return AO_INPROGRESS;
> }
>
> +/*
> + * A "cdrom insert" is always processed as "eject" + "insert", with
> + * updating JSON in between. So that we can know the current state of
> + * CDROM later when we try to retrieve domain configuration: if
> + * xenstore is "empty", then CDROM is "empty"; otherwise use the image
> + * in JSON.
I think you could short circuit the case where the user inserts an empty
disk (AKA ejects), right now you will eject twice. (We don't have an
explicit libxl_cdrom_eject so I presume this is how it is intended to be
done).
I think this function also handles HVM emulated IDE CDROM, which are
semantically a bit different from PV CDROMs in that the empty drive is
still an actual thing. Not sure if/how this impacts on your handling of
the JSON though.
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index b4f518a..f8f2ba2 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -3355,6 +3355,40 @@ static inline void libxl__update_config_vtpm(libxl__gc
> *gc,
> libxl_domain_config_dispose(&d_config); \
> } while (0)
>
> +/* Search device list for device with the same identifier as "dev",
> + * update that device with the content pointed to by "dev".
> + */
> +#define DEVICE_UPDATE_JSON(type, ptr, cnt, domid, dev, compare, rc) \
You could define this in terms of REMOVE+ADD, which would match the
behaviour of the actual operation. Slightly less efficient but less code
perhaps?
If not then I wonder how much of these three macros could be made
common.
> + do { \
> + int x; \
> + libxl_domain_config d_config; \
> + bool updated = false; \
> + \
> + if (domid == LIBXL_TOOLSTACK_DOMID) \
> + break; \
> + \
> + libxl_domain_config_init(&d_config); \
> + \
> + rc = libxl__get_domain_configuration(gc, domid, &d_config); \
> + if (rc) \
> + goto update_done; \
> + \
> + for (x = 0; x < d_config.cnt; x++) { \
> + if (compare(&d_config.ptr[x], (dev))) { \
> + libxl_device_##type##_dispose(&d_config.ptr[x]); \
> + libxl_device_##type##_copy(CTX, &d_config.ptr[x], \
> + (dev)); \
> + updated = true; \
> + } \
> + } \
> + \
> + if (updated) \
> + rc = libxl__set_domain_configuration(gc, domid, &d_config); \
> + \
> + update_done: \
> + libxl_domain_config_dispose(&d_config); \
> + } while (0)
> +
> #endif
>
> /*
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |