Re: [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