From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46806 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PtesM-00087B-3p for qemu-devel@nongnu.org; Sun, 27 Feb 2011 06:33:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PtesK-0004E7-OK for qemu-devel@nongnu.org; Sun, 27 Feb 2011 06:33:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PtesK-0004Du-EY for qemu-devel@nongnu.org; Sun, 27 Feb 2011 06:33:20 -0500 Message-ID: <4D6A3679.1010009@redhat.com> Date: Sun, 27 Feb 2011 13:33:13 +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> In-Reply-To: <4D669476.2030601@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/24/2011 07:25 PM, Anthony Liguori wrote: >> Is it really necessary? What's blocking us from initializing >> chardevs early? > > > Well.... > > We initialize all chardevs at once right now and what set of chardevs > there are depends on the machine (by the way defaults are applied). > You could initialize chardevs in two stages although that requires > quite a bit of additional complexity. We could initialize chardevs on demand - that should resolve any dependencies? > >> >> 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? > > 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? > 3) By treating QMP as a special case, we don't have to treat chardevs > overall as a special case. This feels more right to me although I > can't say I have a strong opinion formed yet. > >> >>> 2) Make qemu_machine_init() take no parameters and just reference >>> global state. >>> >>> 3) Teach all QMP functions to behave themselves if called before >>> qemu_machine_init() >>> >>> 4) Introduce QMP function to call qemu_machine_init() >> >> An alternative is to remove all guest-visible content from >> qemu_machine_init(). So machine->init() would take no parameters and >> only build the static devices (power supply?). Everything else would >> be hot-plugged (perhaps some would fail if the machine was started - >> cold-plug only). > > All that qemu_machine_init() is is guest-visible content. That's the > point of refactoring this. Sorry, poorly phrased. Configurable guest visible content. >>> >>> (6) can be started right now. (1) comes with the QAPI merge. (2) >>> is pretty easy to do after applying this patch. (3) is probably >>> something that can be done shortly after (1). (4) and (5) really >>> require everything but (6) to be in place before we can meaningful >>> do it. >>> >>> I think we can lay out much of the ground work for this in 0.15 and >>> I think we can have a total conversion realistically for 0.16. That >>> means that by EOY, we could invoke QEMU with no options and do >>> everything through QMP. >> >> It's something that I've agitated for a long while, but when I see >> all the work needed, I'm not sure it's cost effective. > > There's a lot of secondary benefits that come from doing this. QMP > becomes a much stronger interface. A lot of operations that right now > are only specifiable by the command line become dynamic which > mitigates reboots in the long term. Only the hot-pluggable ones. > It also lays the ground work for a fully decoupled device model > whereas the only interface between the devices and the outside world > is a subset of QMP (think seccomp()). > > Whether creating a machine with no command line options is high value > is probably irrelevant. I think we want to go in this direction > regardless. I agree it's a good thing. -- error compiling committee.c: too many arguments to function