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