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

[Corey Bryant]

On 06/27/2012 05:51 AM, Kevin Wolf wrote:
> 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
>

Are there any more thoughts on how to move forward with this?  It seems 
like we're at a stand-still with the discussion.

-- 
Regards,
Corey