qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

[Mark Mielke]

On Thu, Aug 20, 2020 at 11:48 AM Christian Ehrhardt <
christian.ehrhardt at canonical.com> wrote:

> On Thu, Aug 20, 2020 at 5:15 PM Mark Mielke <mark.mielke at gmail.com> wrote:
> > On Thu, Aug 20, 2020 at 8:55 AM Christian Ehrhardt <
> christian.ehrhardt at canonical.com> wrote:
> >> This was meant for upgrades, but if libvirt would define a known path in
> >> there like /var/run/qemu/last_packaging_change the packages could easily
> >> touch it on any install/remove/update as Daniel suggested and libvirt
> could
> >> check this path like it does with the date of the qemu binary already.
> > Earlier in this thread - I think one or two of us had asked about the
> timestamp on the directory that contains the modules.
> > I'm wondering if a "last_packaging_change" provides any value over and
> above the timestamp of the directory itself? Wouldn't the directory be best
> - as it would work automatically for both distro packaging as well as
> custom installs?
> Sure, if
> - "list of files in module dir"
> - "stat dates of files in module dir"
> would be checked by libvirt that would also be a no-op for packaging
> and thereby land faster.
>

Why is the list of files and stat dates needed? Any change done by RPM to
add or remove a file from the directory, should cause the mtime for the
directory to be updated. It doesn't really matter what the change is - it
only matters that the change is detected.

The case for needing to check the files *in* the directory, would be a
concern about the modules keeping the same name, but being updated in
place. I'm doubtful that this ever occurs for real, as it would cause
breakage for running programs. Existing running programs would mmap() or
similar the binaries into memory, and cannot be updated in place. Instead,
the inode remains alive, and a new file is created with the same name, to
replace the old file, and once all file descriptors are closed - the inode
is deleted.

So, unless there is a hierarchical directory structure - I believe checking
the modules directory timestamp is near 100% accuracy for whether modules
were added, removed, or updated using "safe" deployment practices either by
RPM or "make install".


> But I guess there were reasons against it in the discussion before?
>

I don't think there was a follow up discussion on the idea. I think that is
here. :-)


-- 
Mark Mielke <mark.mielke at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200820/a00399a9/attachment-0001.htm>