From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34660 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OLvzY-0002sh-BM for qemu-devel@nongnu.org; Tue, 08 Jun 2010 06:25:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OLvzT-0005HW-JP for qemu-devel@nongnu.org; Tue, 08 Jun 2010 06:25:08 -0400 Received: from mail-ww0-f45.google.com ([74.125.82.45]:58982) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OLvzT-0005HJ-FS for qemu-devel@nongnu.org; Tue, 08 Jun 2010 06:25:03 -0400 Received: by wwb13 with SMTP id 13so3338452wwb.4 for ; Tue, 08 Jun 2010 03:25:01 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4C0E1A79.5050803@redhat.com> Date: Tue, 08 Jun 2010 12:24:57 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1275954730-8196-1-git-send-email-aliguori@us.ibm.com> <201006080412.09213.paul@codesourcery.com> In-Reply-To: <201006080412.09213.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Anthony Liguori , Glauber Costa , qemu-devel@nongnu.org On 06/08/2010 05:12 AM, Paul Brook wrote: >> This series introduces a rather radical change in the way we deal with >> machine definitions in QEMU. > > I think we should aim to eliminate machine_register_core, and design > appropriately. In particular I'd try and avoid adding options that become > trivially redundant once you can easily change the device trees. I agree I don't like patch 13 (the parallel/virtcon/vga/floppy/cdrom QemuOpts). Maybe those QemuOpts can be marked in a way that they're not user-accessible (and though in some cases customizing max_cpus may make sense, that option could also fall in that category). Everything else is very much reasonable in Anthony's patch series, I think. > I'm undecided how much parameterisation it's worth trying to support in the > device tree. IMO the current code has way too much magic, because creating a > new variant involves hacking and rebuilding pc.c. See patch 22/22. There is really no magic involved, even though the compat machines are not yet as config files. > I'm extremely tempted by the extreme approach of punting everything to an > external device tree builder. i.e. remove automagical device reation > altogether. I think this should have been raised when the -readconfig/-writeconfig scheme was proposed and committed. I don't think it's reasonable to block this patch series (or something very much like it) on the grounds that a better device tree description model than QemuOpts can be designed. > The problem with doing clever device tree generation/manipulation inside qemu > is that for anything vaguely nonstandard you're likely to have to hack your > own device tree anyway. Even ram allocation is nontrivial, e.g. the hole below > 4G on the PC, and that's before you start with numa-like layouts. Again, the patch is not making anything worse. > On a similar note, I don't see any point having machine_create_from_core, > we can just ship appropriate config files. I think that's the obvious next step, but there's no reason not to split it at this point. Paolo