From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWqxU-0000iW-Ur for qemu-devel@nongnu.org; Tue, 22 May 2012 11:25:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWqxM-0001I9-QJ for qemu-devel@nongnu.org; Tue, 22 May 2012 11:25:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50530) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWqxM-0001Ds-Gm for qemu-devel@nongnu.org; Tue, 22 May 2012 11:25:04 -0400 Message-ID: <4FBBAFC4.50106@redhat.com> Date: Tue, 22 May 2012 17:24:52 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1337631598-30639-1-git-send-email-coreyb@linux.vnet.ibm.com> <4FBB4BCE.5080905@redhat.com> <4FBBA2F8.1020300@linux.vnet.ibm.com> <4FBBA698.7040805@redhat.com> <4FBBAA59.4050006@redhat.com> In-Reply-To: <4FBBAA59.4050006@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: libvir-list@redhat.com, aliguori@us.ibm.com, Corey Bryant , qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com 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