Re: [Qemu-devel] Re: [PATCH] Split machine creation from the main loop

[Avi Kivity <avi@redhat.com>]

On 02/28/2011 06:01 AM, Anthony Liguori wrote:
>
>>>>
>>>> It would be a pity to divorce the monitor from chardevs, they're 
>>>> really flexible.
>>>
>>> Couple considerations:
>>>
>>> 1) chardevs don't support multiple simultaneous connections.  I view 
>>> this as a blocker for QMP.
>>
>> What do you mean by that?   Something like ,server which keeps on 
>> listening after it a connection is established?
>
> ,server won't allow multiple simultaneous connections.  
> CharDriverStates simply don't have a connection semantic.  There can 
> only be one thing connected to it at a time.  This is why we don't use 
> CharDriverState for VNC.

I meant an extension to ,server that keeps on listening.

>
> We should have another abstraction for connection based backend.  I'll 
> take a go at this when I'm ready to try to get those patches in.

Shouldn't each new connection return a chardev?

>
> Just to be clear though, there is a CharDriverState version of the new 
> QMP server.  This would be a second option for creating a QMP server 
> and it takes a different command line sytnax.
>
>>> 2) Because chardevs don't support multiple connections, we can't 
>>> reasonably hook on things like connect/disconnect which means that 
>>> fd's sent via SCM_RIGHTs have to be handled in a very special way.  
>>> By going outside of the chardev layer, we can let fd's via 
>>> SCM_RIGHTS queue up naturally and have getfd/setfd refer to the fd 
>>> at the top of the queue.  It makes it quite a bit easier to work 
>>> with (I believe Daniel had actually requested this a while ago).
>>
>> I really don't follow... what's the connection between SCM_RIGHTS and 
>> multiple connections?
>
> Monitors have a single fd.  That fd is associated with the monitor and 
> lives beyond the length of the connection to the monitor (recall that 
> chardevs don't have a notion of connection life cycle).  This means if 
> a management tool forgets to do a closefd on an unused fd, there's no 
> easy way for QEMU to automatically clean that up.  IOW, a crashed 
> management tool == fd leak in QEMU.

I guess we could add a close() event to chardev?

-- 
error compiling committee.c: too many arguments to function