From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWrpu-0003NX-KX for qemu-devel@nongnu.org; Tue, 22 May 2012 12:21:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWrps-0002tZ-JW for qemu-devel@nongnu.org; Tue, 22 May 2012 12:21:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWrps-0002sq-9x for qemu-devel@nongnu.org; Tue, 22 May 2012 12:21:24 -0400 Message-ID: <4FBBBBB8.5010202@redhat.com> Date: Tue, 22 May 2012 10:15:52 -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> <4FBBB0E3.8030208@linux.vnet.ibm.com> In-Reply-To: <4FBBB0E3.8030208@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigA6479CF0C07250312B585BCF" 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: Corey Bryant Cc: Kevin Wolf , libvir-list@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA6479CF0C07250312B585BCF Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 05/22/2012 09:29 AM, Corey Bryant wrote: >>> I understand that open("/dev/fd/42") would be the same as dup(42), bu= t >>> I'm not sure that I'm entirely clear on how this would work. Could y= ou >>> 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=3D/dev/fd/20 (from libvirt's perspective) is wrong; if qemu will be opening /dev/fd, it has to be /dev/fd/42. 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= =2E >> 42 >> (qemu) drive_add 0 file=3D/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 >> >=20 > 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 perhap= s > 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. >=20 > I'm not sure why getfd would have to return the fd though. I'm assumin= g > this would be the fd returned from open("dev/fd/42"). No. That happens later. That is, when libvirt does 'drive_add 0 file=3D/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. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigA6479CF0C07250312B585BCF 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/ iQEcBAEBCAAGBQJPu7u4AAoJEKeha0olJ0NqcTEH+gPuw7jBIYrlu8PtXtIgAJAA E7997pOpcCYx0kB/wKuRejvevg+Db2u0Ykls2LCUn2vufCwxnU4sEQZOcTVOoGYU Fw/3XZ7vm80uE84Tz9LskDxChrjF+InHWLdSoFJPb7WELzFcsgBAqst1u10ux+tV Hv8n15T2S2bI8j7UEbPHuo76iBcQ0ncJFDLXuSYRHJDw34E7239fpswMmQXZs3Pl C4SnHPjVuRim+d0KbPSnqHAksV8pTVjsScJBxqIcmMrzvWTVXhm8ZeJfv+Ob8gug xGssrecdpWZKKsGjLRfi2tSsLmiAzJF/jRQX7B0iHzIV+OcD7R+pFzwypJGAo20= =7fv0 -----END PGP SIGNATURE----- --------------enigA6479CF0C07250312B585BCF--