search for: qmp_commands_tree

...-device ? */ + char *qmp_commands; /* Output of QMP query-commands. */ + char *qmp_schema; /* Output of QMP query-qmp-schema. */ /* The following fields are derived from the fields above. */ struct version qemu_version; /* Parsed qemu version number. */ + yajl_val qmp_commands_tree; /* qmp_commands parsed into a JSON tree */ + yajl_val qmp_schema_tree; /* qmp_schema parsed into a JSON tree */ }; static int test_qemu_help (guestfs_h *g, struct qemu_data *data); @@ -61,12 +67,20 @@ static int write_cache_qemu_help (guestfs_h *g, const struct qemu_data *data, co stat...

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.

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.