[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH 0/22] Refactor machine support
From: |
Paolo Bonzini |
Subject: |
[Qemu-devel] Re: [PATCH 0/22] Refactor machine support |
Date: |
Tue, 08 Jun 2010 12:24:57 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Lightning/1.0b2pre Thunderbird/3.0.4 |
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
- [Qemu-devel] [PATCH 21/22] machine: convert pc machines to split core vs machine API, (continued)
- [Qemu-devel] [PATCH 20/22] machine: introduce machine core and split qemu_register_machine, Anthony Liguori, 2010/06/07
- [Qemu-devel] [PATCH 18/22] machine: final conversion to pure QemuOpts, Anthony Liguori, 2010/06/07
- Re: [Qemu-devel] [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/07
- [Qemu-devel] Re: [PATCH 0/22] Refactor machine support,
Paolo Bonzini <=
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paolo Bonzini, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Alexander Graf, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/09