Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support

[Paolo Bonzini <pbonzini@redhat.com>]

On 06/08/2010 05:36 PM, Paul Brook wrote:
>>>    Once you eliminate machine_register_core that knowledge has
>>>
>>> somehow got to come from your device tree description file.  Having a
>>> single device tree that can morph into significantly different machines
>>> seems like unnecessary complexity given this is a user-specified file.
>>
>> 99% of qemu users will never touch a device tree.  The practical matter
>> is, we're going to have to provide higher level interfaces that allow a
>> user to significantly morph a base device tree into something different.
>
> That's the bit I don't get.  Why are we significantly morphing a base device
> tree?  Surely it's easier to just use a different base tree.

Because at some point the base tree will have to be written in C.  Of 
course you have to decide where to stop allowing customization, but 
anyway it will be significantly more complex than a QemuOpts config 
file.  QemuOpts obviously doesn't have the flexibility to create an 
entire device tree.

Want to let the user add an IDE controller?  Fine, you need to provide 
him with a way of writing the following logic:

     for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) {
         hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
     }
     pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1);

What do you do?  Invent your own language (another YaST? no thanks)? 
Massive refactoring of QEMU's bowels (cannot solve all the problems, 
Anthony gave more examples in the email I replied to)?  Keep C code 
(then you're not doing anything different than what Anthony's 
MachineCore is doing)?


I think there are four choices:

1) only merge the first 5-7 patches of the series, basically up to the 
creation of -machine and conversion of -kernel/-initrd/-M/-m.  This is 
also what is needed for KVM's irqchip.  Think about some other smart way 
to implement default devices.

2) do not expose some things to the config files.  This requires 
implementing an additional QemuOpts feature for internal options, plus 
the current patchset.  It means that moving machine types out to config 
files is not possible.

3) put some things into an implementation-dependent namespace, i.e. 
__pci or __default_device or __serial.  In the future it's possible to 
these things in config files, just nobody has to worry about users 
relying on them and can refactor to death.  This is the current patchset 
plus some search and replace, and is my favorite.

4) expose everything to the user, at the cost of regretting it later. 
This is the current patchset.


One "smart way to implement default devices" could be an inclusion 
mechanism where a machine can ask qemu to read other config files.  Then 
you'd have config files for the default serial/parallel/etc.  This could 
also be implemented on top of choices 2/3/4 though.

Paolo