search for: memo_generation

...---------------------- 1 file changed, 238 insertions(+), 137 deletions(-) diff --git a/lib/qemu.c b/lib/qemu.c index 48e283d48..bdd9947a8 100644 --- a/lib/qemu.c +++ b/lib/qemu.c @@ -44,6 +44,10 @@ #include "guestfs_protocol.h" struct qemu_data { + int generation; /* MEMO_GENERATION read from qemu.stat */ + uint64_t prev_size; /* Size of qemu binary when cached. */ + uint64_t prev_mtime; /* mtime of qemu binary when cached. */ + char *qemu_help; /* Output of qemu -help. */ char *qemu_devices; /* Output of qemu -device ? */ @@...

...o if we decide to change the > +/* This is saved in the qemu-*.stat file, so if we decide to change the > * test_qemu memoization format/data in future, we should increment > * this to discard any memoized data cached by previous versions of > * libguestfs. > */ > -#define MEMO_GENERATION 2 > +#define MEMO_GENERATION 3 Maybe just a nitpick: since this commit just changes the location of the cached files, but keeps the format unchanged, then I guess bumping MEMO_GENERATION is not strictly needed. -- Pino Toscano

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.

...l (guestfs_h *g, void *retv, const char *buf, size_t len); +/* This is saved in the qemu.stat file, so if we decide to change the + * test_qemu memoization format/data in future, we should increment + * this to discard any memoized data cached by previous versions of + * libguestfs. + */ +#define MEMO_GENERATION 1 + /** * Test qemu binary (or wrapper) runs, and do C<qemu -help> so we know * the version of qemu what options this qemu supports, and * C<qemu -device ?> so we know what devices are available. + * + * This caches the results in the cachedir so that as long as the qemu + * bina...

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.

...saved in the qemu.stat file, so if we decide to change the +/* This is saved in the qemu-*.stat file, so if we decide to change the * test_qemu memoization format/data in future, we should increment * this to discard any memoized data cached by previous versions of * libguestfs. */ -#define MEMO_GENERATION 2 +#define MEMO_GENERATION 3 /** * Test that the qemu binary (or wrapper) runs, and do C<qemu -help> @@ -147,7 +148,7 @@ guestfs_int_test_qemu (guestfs_h *g) data = safe_calloc (g, 1, sizeof *data); - stat_filename = safe_asprintf (g, "%s/qemu.stat", cachedir); + stat_...

...HAVE_ATTRIBUTE_CLEANUP +#define CLEANUP_JSON_T_DECREF __attribute__((cleanup(cleanup_json_t_decref))) + +static void +cleanup_json_t_decref (void *ptr) +{ + json_decref (* (json_t **) ptr); +} + +#else +#define CLEANUP_JSON_T_DECREF +#endif + struct qemu_data { int generation; /* MEMO_GENERATION read from qemu.stat */ uint64_t prev_size; /* Size of qemu binary when cached. */ @@ -54,10 +67,12 @@ struct qemu_data { char *qemu_help; /* Output of qemu -help. */ char *qemu_devices; /* Output of qemu -device ? */ char *qmp_schema; /* Outp...

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.

Hi, this patch series fixes few more issues discovered by Coverity. Thanks, Pino Toscano (6): tail: check the return value pf guestfs_set_pgroup daemon: btrfs: check end_stringsbuf return values everywhere java: use cleanup handlers for structs (lists) as return values lib: qemu: improve handling of FILE* p2v: check more return values p2v: fix possible close(-1) issue cat/tail.c

...quot;, + test_qmp_schema, read_cache_qmp_schema, write_cache_qmp_schema }, }; #define NR_FIELDS (sizeof qemu_fields / sizeof qemu_fields[0]) @@ -97,7 +115,7 @@ static const struct qemu_fields { * this to discard any memoized data cached by previous versions of * libguestfs. */ -#define MEMO_GENERATION 1 +#define MEMO_GENERATION 2 /** * Test that the qemu binary (or wrapper) runs, and do C<qemu -help> @@ -152,8 +170,16 @@ guestfs_int_test_qemu (guestfs_h *g) r = qemu_fields[i].read_cache (g, data, filename); if (r == -1) goto error; - if (r == 0) /* cache gone, mayb...

Patches 1 & 2 were posted previously here: https://www.redhat.com/archives/libguestfs/2016-May/msg00134.html Patch 3 is a hack so I can test this using my own version of qemu (the `-L ?' stuff is not upstream). Patch 4 is where the real action takes place: Replace the caching of qemu features in blob-like files with a sqlite database. Probably the best way to approach this patch is to

Doing qemu feature detection in the direct backend takes ~100ms because we need to run `qemu -help' and `qemu -devices ?', and each of those interacts with glibc's very slow link loader. Fixing the link loader is really hard. Instead memoize the output of those two commands. This patch series first separates all the code dealing with qemu into a separate module (src/qemu.c) and

v1 -> v2: - Rebase on top of Pino's version work. Two patches went upstream, these are the two remaining patches. Note the generation number is still inside the qemu.stat file. We could put it in the filename, I have no particular preference. Rich.