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

[Paul Brook <paul@codesourcery.com>]

> > 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.

The magic I'm preferring to is precisely things like pci="on".
This is an artifact of only having a hardcoded single device tree (defined by 
pc_init), so we need magic parameters to pick between different variants.

If this were just a cleanup of how we implement the various machines that 
would be harmless. However these are now a user-visible interface.

It implies that qemu is expected to know how to add/remove PCI capabilities 
from a machine. 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.

> > 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.

I don't see how the introduction of QemuOpts is relevant. That's just a 
flexible commandline option handling system, which makes a lot of sense.

What I'm objecting to is making machine construction be controlled by an 
arbitrary set of hardcoded parameters. One of the goals of the qdev work is 
that you don't need to have hardcoded all the interesting ways a machine can 
vary. Instead you can directly specify how to construct the machine.

My argument is that in the short term this parameterization provides limited 
benefit, and longer term it's going to be obsolete and probably painful to 
support.

Paul