[libvirt] [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file

[Corey Bryant]

On 05/22/2012 12:15 PM, Eric Blake wrote:
> On 05/22/2012 09:29 AM, Corey Bryant wrote:
>
>>>> I understand that open("/dev/fd/42") would be the same as dup(42), but
>>>> I'm not sure that I'm entirely clear on how this would work.  Could you
>>>> give an example?
>>>
>
>>> Instead you could use the existing getfd command and avoid the
>>> translation:
>>>
>>> (qemu) getfd
>
> Really, this would be:
>
> (qemu) getfd name
>
> Here, libvirt may be passing in fd 20 (from the livirt process), which
> qemu then receives as fd 42 (in the qemu process).  Libvirt needs to
> know that qemu sees the file as 42, because a file=/dev/fd/20 (from
> libvirt's perspective) is wrong; if qemu will be opening /dev/fd, it has
> to be /dev/fd/42.

This clears things up a lot.

>
> If you pass the fd's by inheritance at the command line when first
> exec'ing qemu, then libvirt's fd number _is_ qemu's fd number, so it is
> only the 'getfd' command that needs to be enhanced to return an fd number.
>

Ok

>>> 42
>>> (qemu) drive_add 0 file=/dev/fd/42,...
>>>
>>> Er, well. Just that getfd doesn't return the assigned fd today, so the
>>> management tool doesn't know it. We would have to add that.
>>>
>>> Kevin
>>>
>>
>> Thanks for the explanation.  This would mean the management app that
>> performs the open(/path/to/my.img) would have to keep a mapping of
>> filenames (/path/to/my.img) to corresponding /dev/fd/X paths, or perhaps
>> just keeping track of the filename and fd is enough.  It sounds like
>> this would simplify things in QEMU and get rid of any need for
>> canonicalization of filenames in QEMU.
>
> Libvirt would just track the int fd returned by 'getfd' as associated
> with the device it has handed to qemu, and construct a /dev/fd/X path
> based on that int.  Not too difficult.
>

Ok

>>
>> I'm not sure why getfd would have to return the fd though.  I'm assuming
>> this would be the fd returned from open("dev/fd/42").
>
> No.  That happens later.  That is, when libvirt does 'drive_add 0
> file=/dev/fd/42', then qemu does open("/dev/fd/42") and gets a _new_ fd,
> which is basically the result of dup(42).  After the 'drive_add'
> succeeds, _then_ libvirt follows up with a 'closefd name' that matches
> the name passed in to the original 'getfd', so that qemu will call
> close(42) at that point.  The added drive continues to use the
> duplicated fd.
>

That makes sense.  Thanks!

-- 
Regards,
Corey