On 06/08/2010 10:58 AM, Paolo Bonzini wrote:
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)?
Or punt all of the complexity to the user such that have to manually
figure out where in the device tree a drive has to be inserted. That's
not really reasonable IMHO.
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.
Or don't declare MachineCore options stable across releases. I concur
that we probably don't want to support some of these interfaces long
term but I think we can pretty quickly figure out some better interfaces.
The advantage of a full conversion is that it allows us to focus on
improving the interfaces since we'll have the architecture in place.
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.
I dislike having internal only options as it means we have to keep
things within qemu. For things like max_cpus, I think we just need to
validate that we've got passed sane values. Setting max_cpus in a
global config is actually a really useful thing for downstreams to do
since they are all having a fixed support statement of X VCPUs per VM.
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.
Yeah, I'm good with being explicit. I'd prefer x-pci or x-serial since
we've already established that as the experimential namespace.
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.
Default devices are a real pain. Fortunately, we only mess with it in
s390 so I'm fairly certain we can simplify things considerable. It's
just not something I wanted to tackle in this series.
Regards,
Anthony Liguori
Paolo
