From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60661) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWsid-0000nB-39 for qemu-devel@nongnu.org; Tue, 22 May 2012 13:18:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWsib-0003Fi-0I for qemu-devel@nongnu.org; Tue, 22 May 2012 13:17:58 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:32931) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWsia-0003F0-PO for qemu-devel@nongnu.org; Tue, 22 May 2012 13:17:56 -0400 Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 22 May 2012 11:17:52 -0600 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id CE09BC90060 for ; Tue, 22 May 2012 13:17:45 -0400 (EDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4MHHkmA088662 for ; Tue, 22 May 2012 13:17:46 -0400 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q4MHIT5B003361 for ; Tue, 22 May 2012 11:18:30 -0600 Message-ID: <4FBBCA37.1000700@linux.vnet.ibm.com> Date: Tue, 22 May 2012 13:17:43 -0400 From: Corey Bryant 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> <4FBBBBB8.5010202@redhat.com> In-Reply-To: <4FBBBBB8.5010202@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed 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: Kevin Wolf , libvir-list@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com On 05/22/2012 12:15 PM, Eric Blake wrote: > On 05/22/2012 09:29 AM, Corey Bryant 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? >>> > >>> 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=/dev/fd/20 (from > libvirt's perspective) is wrong; if qemu will be opening /dev/fd, it has > to be /dev/fd/42. This clears things up a lot. > > 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. > Ok >>> 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. >>> >>> Kevin >>> >> >> 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 perhaps >> 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. > Ok >> >> I'm not sure why getfd would have to return the fd though. I'm assuming >> this would be the fd returned from open("dev/fd/42"). > > No. That happens later. That is, when libvirt does 'drive_add 0 > file=/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. > That makes sense. Thanks! -- Regards, Corey