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 <kw...@redhat.com> 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
