Re: [libvirt] [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd

Am 27.06.2012 11:20, schrieb Daniel P. Berrange: > On Wed, Jun 27, 2012 at 11:16:32AM +0200, Kevin Wolf wrote: >> The really bad case that nobody thought of is that, when block-commit >> has finished, we need to switch back to read-only. This is an event that >> is not triggered by a certain monitor command, but that comes from >> inside qemu. I'm almost sure that we'll see more of this as we add more >> asynchronous commands. >> >> This only works if we can pass the new file descriptor in advance. It >> would work nicely if you go with pass-fd and actually maintain a list of >> file descriptors for each /dev/fd/N, along with the different flags the >> file descriptors are meant for. I can't see how it would work with the >> temporary /dev/fdlist/N or the fd:name approach because they both imply >> that the original file descriptors are closed by the time that the QMP >> command returns. > > What I don't understand though is that when you're "reopening" FDs, with > the pass-fd command approach, you're merely dup'ing the original FDs that > was passed in from the client. Why can't you alternatively just dup the > FD you already have. That's easy: Because I don't know that I'm dealing with an FD. I think originally the whole point in this /dev/fd/ thing was that it would transparently enable the functionality for all parts of qemu: The block layer, of course, but also new char devices, migration targets, screenshot files or whatever else can deal with files. In this design the block layer doesn't even know that it's not a regular file. If we now decided to go for a design where the /dev/fd path isn't enough, but changes are needed to each subsystem where it should work, then this point doesn't apply any more and I cast my vote for abandoning everything starting with /dev/ and introducing a proper fd: protocol in the block layer, so that the block layer at least has a chance to know that it has to do treat this file specially. > I don't see why we need to keep the original FD > around forever. If the QMP command handler nees the temporary /dev/fdlist/N > file to exist for longer than the duration of the command, it can simply > dup() it to get a permanent copy of its own. If we're not going to make it transparent and if we don't care about QMP command bloat, we can choose completely different designs, yes. And then qemu could probably try to internally work around a suboptimal API. Kevin