qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

Mark Mielke mark.mielke at gmail.com
Thu Aug 20 21:27:32 UTC 2020


On Thu, Aug 20, 2020 at 2:01 PM Daniel P. Berrangé <berrange at redhat.com>
wrote:

> 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.
>

Yep, correct.


> 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.
>

I think this is the relevant section of the Makefile:

ifneq ($(CONFIG_MODULES),)
        $(INSTALL_DIR) "$(DESTDIR)$(qemu_moddir)"
        for s in $(modules-m:.mo=$(DSOSUF)); do \
                t="$(DESTDIR)$(qemu_moddir)/$$(echo $$s | tr / -)"; \
                $(INSTALL_LIB) $$s "$$t"; \
                test -z "$(STRIP)" || $(STRIP) "$$t"; \
        done
endif


The INSTALL_LIB is detected by configure, and will normally be:

config-host.mak:INSTALL_LIB=install -c -m 0644


You can see here that "install" results in a new inode, which indicates a
new file:

$ cd /tmp
$ install -c -m 0644 /etc/motd motd_temp
$ ls -li motd_temp
*3544372* -rw-r--r-- 1 mark mark 0 Aug 20 17:25 motd_temp
$ install -c -m 0644 /etc/motd motd_temp
$ ls -li motd_temp
*3561572* -rw-r--r-- 1 mark mark 0 Aug 20 17:25 motd_temp


Once upon a time, this wasn't done - and the consequence is that things
like "make install" would break running programs with various undefined
behaviour. Now it is done "correctly" for so long, that people may have
forgotten the old days. :-)

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


More information about the libvir-list mailing list