From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48847 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsddT-0004of-ME for qemu-devel@nongnu.org; Thu, 24 Feb 2011 11:01:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsddS-0005mK-KH for qemu-devel@nongnu.org; Thu, 24 Feb 2011 11:01:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47297) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsddS-0005mF-6I for qemu-devel@nongnu.org; Thu, 24 Feb 2011 11:01:46 -0500 Message-ID: <4D6680E3.8010802@redhat.com> Date: Thu, 24 Feb 2011 18:01:39 +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> In-Reply-To: <4D65945A.3090106@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 01:12 AM, Anthony Liguori wrote: >> What is the plan from here? > > > 1) Decouple QMP from qemu_machine_init(). This really requires the > introduction of the new QAPI server that exists outside of the chardev > infrastructure since chardevs are currently initialized in > qemu_machine_init(). Is it really necessary? What's blocking us from initializing chardevs early? It would be a pity to divorce the monitor from chardevs, they're really flexible. > 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). > > 5) Introduce new command line flag to not automatically call > qemu_machine_init() > > 6) Convert all command line options to just be QMP function calls > > (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. -- error compiling committee.c: too many arguments to function