Re: qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 20, 2020 at 2:01 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> 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@xxxxxxxxx>


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux