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