search for: guestfs_int_qemu_mandatory_lock

...struct version guestfs_int_qemu_version (guestfs_h *g, struct qemu_data *); extern int guestfs_int_qemu_supports (guestfs_h *g, const struct qemu_data *, const char *option); extern int guestfs_int_qemu_supports_device (guestfs_h *g, const struct qemu_data *, const char *device_name); +extern int guestfs_int_qemu_mandatory_locking (guestfs_h *g, const struct qemu_data *data); extern char *guestfs_int_drive_source_qemu_param (guestfs_h *g, const struct drive_source *src); extern bool guestfs_int_discard_possible (guestfs_h *g, struct drive *drv, const struct version *qemu_version); extern char *guestfs_int_qemu_escape_p...

...iance is not > started; so code like `guestfish disk-format foo` will be slower. > OTOH, the upside is that there is no need to "reprobe" qemu-img for > something that we detect already from the QMP schema. So I had a look into this. I guess you mean specifically the result of ‘guestfs_int_qemu_mandatory_locking’ which queries the QMP schema. This is a reasonable proxy for presence of the qemu-img -U option since both features were added within a few months. However the problem is that testing for this requires us to run qemu before launch is called. That has API issues because it's unclear what c...

...disk-format foo` will be slower. > > > OTOH, the upside is that there is no need to "reprobe" qemu-img for > > > something that we detect already from the QMP schema. > > > > So I had a look into this. I guess you mean specifically the result > > of ‘guestfs_int_qemu_mandatory_locking’ which queries the QMP schema. > > This is a reasonable proxy for presence of the qemu-img -U option > > since both features were added within a few months. > > > > However the problem is that testing for this requires us to run qemu > > before launch is called. T...

...n struct version guestfs_int_qemu_version (guestfs_h *g, struct qemu_data * extern int guestfs_int_qemu_supports (guestfs_h *g, const struct qemu_data *, const char *option); extern int guestfs_int_qemu_supports_device (guestfs_h *g, const struct qemu_data *, const char *device_name); extern int guestfs_int_qemu_mandatory_locking (guestfs_h *g, const struct qemu_data *data); +extern bool guestfs_int_platform_has_kvm (guestfs_h *g, const struct qemu_data *data); extern char *guestfs_int_drive_source_qemu_param (guestfs_h *g, const struct drive_source *src); extern bool guestfs_int_discard_possible (guestfs_h *g, struct...

...direct (guestfs_h *g, void *datav, const char *arg) data->qemu_version = guestfs_int_qemu_version (g, data->qemu_data); debug (g, "qemu version: %d.%d", data->qemu_version.v_major, data->qemu_version.v_minor); + data->qemu_mandatory_locking = + guestfs_int_qemu_mandatory_locking (g, data->qemu_data); + debug (g, "qemu mandatory locking: %s", + data->qemu_mandatory_locking ? "yes" : "no"); } /* Using virtio-serial, we need to create a local Unix domain socket -- 2.13.2

...; so code like `guestfish disk-format foo` will be slower. > > OTOH, the upside is that there is no need to "reprobe" qemu-img for > > something that we detect already from the QMP schema. > > So I had a look into this. I guess you mean specifically the result > of ‘guestfs_int_qemu_mandatory_locking’ which queries the QMP schema. > This is a reasonable proxy for presence of the qemu-img -U option > since both features were added within a few months. > > However the problem is that testing for this requires us to run qemu > before launch is called. That has API issues becaus...

...ndif -#if defined(__GNUC__) && GUESTFS_GCC_VERSION >= 40800 /* gcc >= 4.8.0 */ -#pragma GCC diagnostic ignored "-Wnonnull" -#endif - /** * Test if the qemu binary uses mandatory file locking, added in * QEMU >= 2.10 (but sometimes disabled). @@ -599,11 +588,7 @@ int guestfs_int_qemu_mandatory_locking (guestfs_h *g, const struct qemu_data *data) { - const char *return_path[] = { "return", NULL }; - const char *meta_type_path[] = { "meta-type", NULL }; - const char *members_path[] = { "members", NULL }; - const char *name_...

...ndif -#if defined(__GNUC__) && GUESTFS_GCC_VERSION >= 40800 /* gcc >= 4.8.0 */ -#pragma GCC diagnostic ignored "-Wnonnull" -#endif - /** * Test if the qemu binary uses mandatory file locking, added in * QEMU >= 2.10 (but sometimes disabled). @@ -599,11 +588,7 @@ int guestfs_int_qemu_mandatory_locking (guestfs_h *g, const struct qemu_data *data) { - const char *return_path[] = { "return", NULL }; - const char *meta_type_path[] = { "meta-type", NULL }; - const char *members_path[] = { "members", NULL }; - const char *name_...

Hi, recently, there was a discussion in the development list of libvirt on switching to a different JSON library than YAJL [1]. Since we use YAJL, and the points there IMHO apply to libguestfs as well, I decided to give a try in switching to Jansson [2]. The result IMHO is nice, with the additional APIs of Jansson that simplify some of our code. Unlike with YAJL, I did not set a minimum

Hi, recently, there was a discussion in the development list of libvirt on switching to a different JSON library than YAJL [1]. Since we use YAJL, and the points there IMHO apply to libguestfs as well, I decided to give a try in switching to Jansson [2]. The result IMHO is nice, with the additional APIs of Jansson that simplify some of our code. Unlike with YAJL, I did not set a minimum

v2 -> v3: - I addressed everything that Pino mentioned last time. - It's tricky to get a stable run when multiple copies of qemu are involved, because the same cache files get overwritten by parallel libguestfs. So I changed the names of the cache files to include the qemu binary key (size, mtime), which removes this conflict. This is in new patch 4/6. Rich.

Patches 1-4 are almost the same as they are when previously posted here: https://www.redhat.com/archives/libguestfs/2017-September/msg00039.html Patch 5 actually uses the mandatory locking test to turn off locking in the narrow case where a drive is opened readonly, and then only for the drive being inspected. Passes ordinary tests (‘check-direct’ and ‘check-valgrind-direct’). Rich.

https://bugs.launchpad.net/qemu/+bug/1740364 --- lib/guestfs-internal.h | 3 +++ lib/handle.c | 2 ++ lib/info.c | 39 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 44 insertions(+) diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h index adeb9478a..c66c55e70 100644 --- a/lib/guestfs-internal.h +++ b/lib/guestfs-internal.h @@ -510,6 +510,9 @@ struct

The patch I posted last week to disable mandatory locking for readonly drives (https://www.redhat.com/archives/libguestfs/2017-September/msg00013.html) was wrong in a couple of respects. Firstly it didn't work, which I didn't detect because my tests were testing the wrong thing. Oops. Secondly it used a simple version number check to detect qemu binaries implementing mandatory locking.