qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

[Daniel P. Berrangé]

On Thu, Aug 20, 2020 at 11:42:45AM -0600, Jim Fehlig wrote:
> On 8/20/20 10:54 AM, Mark Mielke wrote:
> > On Thu, Aug 20, 2020 at 11:48 AM Christian Ehrhardt
> > <christian.ehrhardt at canonical.com
> > <mailto:christian.ehrhardt at canonical.com>> wrote:
> > 
> >     On Thu, Aug 20, 2020 at 5:15 PM Mark Mielke <mark.mielke at gmail.com
> >     <mailto:mark.mielke at gmail.com>> wrote:
> >      > On Thu, Aug 20, 2020 at 8:55 AM Christian Ehrhardt
> >     <christian.ehrhardt at canonical.com <mailto: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".
> 
> I wrote a small test program that checks mtime (also tried ctime) and it
> only changes on the directory when files are added and deleted. There is no
> change to either if a file in the directory has been updated. It would be
> really convenient to check only the directory to see if its' contents have
> changed but I'm not aware of how to do that other than with something like
> inotify. Suggestions welcomed.

IIUC, Mark's point is that an RPM update won't replace the file in-placec.
It will write out a new temporary file and then rename over the top of the
old file, which should trigger an update on the directory mtime.

Not sure what a "make install" will do with QEMU, but since QEMU is about
to switch to meson, we might get lucky in having the same temp+rename
behaviour.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|