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

[Avi Kivity]

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