On Tue, 2020-08-18 at 15:15 -0600, Jim Fehlig wrote: > On 8/5/20 2:19 AM, Andrea Bolognani wrote: > > > > I guess we need to start checking the modules directory in addition > > to the main QEMU binary, and regenerate capabilities every time its > > contents change. > > We recently received reports of this issue on Tumbleweed, which just > got the > modularized qemu 5.1 > > https://bugzilla.opensuse.org/show_bug.cgi?id=1175320 > > Mark, are you working on a patch to invalidate the cache on changes > to the qemu > modules directory? I suppose it needs to be handled similar to the > qemu > binaries. E.g. when building the cache include a list of all qemu > modules found. > When validating the cache see if any modules have disappeared, if any > have been > added, and if the ctime of any have changed. Yikes, sounds a little > more complex > than the binaries :-). I'd like to question whether this effort is justified for an optimization that matters only at libvirtd startup time, and even there saves no more than a few seconds. I propose to simply disable the caching of qemu capabilities (or provide a build-time option to do so). Optimizations that produce wrong results should be avoided. > I wonder if it is possible to use inotify to receive notification of > changes to > the modules directory? That would certainly be possible, but it'd be a new feature (getting aware of qemu capability changes during runtime), while we're currently discussing an existing feature (getting qemu capabilities on startup) which is broken. I believe these issues should be discussed separately. Regards, Martin
