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

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.

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