From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51168 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PtyO8-0006Tq-Ed for qemu-devel@nongnu.org; Mon, 28 Feb 2011 03:23:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PtyLD-0003Wn-Ow for qemu-devel@nongnu.org; Mon, 28 Feb 2011 03:20:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PtyLD-0003WQ-Cd for qemu-devel@nongnu.org; Mon, 28 Feb 2011 03:20:27 -0500 Message-ID: <4D6B5AC2.8050004@redhat.com> Date: Mon, 28 Feb 2011 10:20:18 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Split machine creation from the main loop References: <1298497114-7436-1-git-send-email-aliguori@us.ibm.com> <4D65945A.3090106@codemonkey.ws> <4D6680E3.8010802@redhat.com> <4D669476.2030601@codemonkey.ws> <4D6A3679.1010009@redhat.com> <4D6B1E1D.2050801@codemonkey.ws> In-Reply-To: <4D6B1E1D.2050801@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, quintela@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