Am 19.06.2012 18:14, schrieb Eric Blake: >> Maybe it's better to have a monitor command that just prepares a reopen >> and means "for the next reopen of /dev/fd/42, the passed FD will have >> the right flags (if it hasn't, the reopen will fail)". We can use dup2() >> to keep the "name" stable. > > Indeed, having one additional up-front command in the pass-fd/closefd > family might make this easier. But how would it work reliably? > Remember, the current proposal is: > > libvirt opens backing file O_RDONLY, and calls 'pass-fd name' > qemu returns 21 > libvirt tells qemu to hotplug a drive with /dev/fd/21 as backing file > qemu dup()s 21, and proceeds to use fd 22 for all its real work > libvirt calls 'closefd name', to avoid the leak on fd 21 Right, I didn't consider that we really use a dup()ed fd. I'm not completely clear about when libvirt should call closefd, and what the lifetime of fd 21 is. If I'm not mistaken, the reason for using dup() and requiring an explicit closefd was that qemu can reopen the file multiple times, for example for probing, but it's basically the same with commit. If so, nothing else must become fd 21 while the image is still in use as qemu might decide to reopen. This might mean that libvirt should only closefd the file when it becomes unused (like after hot unplug); or that qemu must keep it open internally even after closefd as long as the block device is still in use. Kevin -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list