Re: [libvirt] [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd

Am 27.06.2012 00:54, schrieb Eric Blake: >> It seems like libvirt would be in a better position to understand when a >> file is no longer in use, and then it can call close_fd. No? Of course >> the the only fd that needs to be closed is the originally passed fd. The >> dup'd fd's are closed by QEMU. > > The more we discuss this, the more I'm convinced that commands like > 'block-commit' that will reopen a file to change from O_RDONLY to O_RDWR > will need to have an optional argument that says the name of the file to > reopen. That is, I've seen three proposals: Thanks for the summary. In fact, after having read this, I start thinking that we're oversimplifying things because we're only thinking about one use case, block-commit. There are more: Live snapshot doesn't only put a new image on top, it must also make the old top-level image read-only. This isn't bad per se, but it shows that QMP commands can easily become bloated if you decide to change every command. The really bad case that nobody thought of is that, when block-commit has finished, we need to switch back to read-only. This is an event that is not triggered by a certain monitor command, but that comes from inside qemu. I'm almost sure that we'll see more of this as we add more asynchronous commands. This only works if we can pass the new file descriptor in advance. It would work nicely if you go with pass-fd and actually maintain a list of file descriptors for each /dev/fd/N, along with the different flags the file descriptors are meant for. I can't see how it would work with the temporary /dev/fdlist/N or the fd:name approach because they both imply that the original file descriptors are closed by the time that the QMP command returns.