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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list