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
