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

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.

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.

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

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