Am 27.06.2012 00:28, schrieb Corey Bryant:
On 06/26/2012 04:50 PM, Luiz Capitulino wrote:
On Tue, 26 Jun 2012 13:45:52 +0200
Kevin Wolf <address@hidden> wrote:
Am 26.06.2012 11:10, schrieb Daniel P. Berrange:
I was thinking about some of the sources complexity when using
FD passing from libvirt and wanted to raise one idea for discussion
before we continue.
With this proposed series, we have usage akin to:
1. pass_fd FDSET={M} -> returns a string "/dev/fd/N" showing QEMU's
view of the FD
2. drive_add file=/dev/fd/N
3. if failure:
close_fd "/dev/fd/N"
In fact, there are more steps:
4. use it successfully
5. close_fd "/dev/fd/N"
I think it would well be possible that qemu just closes the fd when it's
not used internally any more.
pass-fd could have a flag indicating qemu to do that.
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.
No, libvirt doesn't know it, because the original file descriptor is
still needed when qemu decides to reopen the file. So I think qemu needs
some kind of refcounting anyway. One of the references is held by
libvirt and it can drop it with close_fd, and the other one would be for
the BlockDriverState or whatever you use the FD with. (There's a tricky
part: When do you actually close the FD? If libvirt has dropped its
reference and qemu reopens, for example because it has just probed the
image format, we have a short time where the refcount would be 0, but we
can't drop it anyway.)
Kevin