From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWqb4-0002o5-3l for qemu-devel@nongnu.org; Tue, 22 May 2012 11:02:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWqay-0001sk-Tv for qemu-devel@nongnu.org; Tue, 22 May 2012 11:02:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWqay-0001sJ-A0 for qemu-devel@nongnu.org; Tue, 22 May 2012 11:01:56 -0400 Message-ID: <4FBBAA59.4050006@redhat.com> Date: Tue, 22 May 2012 09:01:45 -0600 From: Eric Blake 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> In-Reply-To: <4FBBA698.7040805@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig52A30EE793D21F56133A966A" 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: Kevin Wolf Cc: libvir-list@redhat.com, aliguori@us.ibm.com, Corey Bryant , qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig52A30EE793D21F56133A966A Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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= =20 >> I'm not sure that I'm entirely clear on how this would work. Could yo= u=20 >> give an example? >=20 > 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: >=20 > (qemu) getfd_file abc > (qemu) drive_add 0 file=3Dabc,... >=20 > Instead you could use the existing getfd command and avoid the translat= ion: >=20 > (qemu) getfd > 42 > (qemu) drive_add 0 file=3D/dev/fd/42,... >=20 > 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=3D/dev/fd/42 dups the fd rather than= consuming it (this is different from commands that use fd:nnn to consume an fd). --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig52A30EE793D21F56133A966A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPu6pZAAoJEKeha0olJ0NqrhEIAKEU7XL8PvwWMISAd5zCGTl5 BP3O8pMt3phNisexB6dsTNabL4hTXSI1UX6UX/bW0JOcSVZVMg4qry3gEdWAzWwb O+22pwtlLIsUwPAu3ZTBSVxIobgvI4L5ATiRAqYyzaWd9ajS/YL8f2qejwn0huuu Gldccb69/cqLIfSbLosjEL+iSpGMhFbDpC2x4c/7S3xsjCO1qhyRLBWTTIAXlCXr xQhqEV3M5wBPumY0YyuMBD6W6DuNJdQYnn6np3Se4w+WjuuL1HkXH/UX5XgwCye4 JwJ/FwBjCH+fE7WNxZMFZ1j86C3PIpftROXb1ReBck4o5ON+XV2E0HjBnuQSink= =6BPe -----END PGP SIGNATURE----- --------------enig52A30EE793D21F56133A966A--