Am 22.05.2012 17:01, schrieb Eric Blake:
On 05/22/2012 08:45 AM, Kevin Wolf 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?
With your approach you open the file outside qemu, pass the fd to qemu along with a file name that it's supposed to replace and then you use that fake file name:
(qemu) getfd_file abc (qemu) drive_add 0 file=abc,...
Instead you could use the existing getfd command and avoid the translation:
(qemu) getfd 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.
That actually sounds workable. As long as management knows _what_ fd qemu recieved (that is, 'getfd' is enhanced to tell libvirt the associated fd number), and as long as qemu makes the magic naming of /dev/fd/ work everywhere (even if it isn't normally part of the host OS), then libvirt could indeed reuse existing file mechanisms to open a file using an fd that it knows qemu should already own, without needing to invent a new 'getfd_file' monitor command.
Which OSes are you thinking of? I'm not sure if we need to support FD passing on all OSes in all places where you can pass a file name. The specific use case we have in mind is for bypassing a SELinux limitation, so that would be useful only for Linux anyway.
I guess in this instance, libvirt would have to unconditionally use 'closefd' after the command that reused the fd, since using file=/dev/fd/42 dups the fd rather than consuming it (this is different from commands that use fd:nnn to consume an fd).
I actually liked the fd: protocol approach, but Anthony doesn't seem to want it any more. But yes, I think if we use /dev/fd/42 you need to closefd unconditionally. Kevin