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

[Eric Blake]

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.

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.

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

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

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature