Re: [Qemu-devel] [PATCH V3 0/5] remove QEMUMachine indirection from MachineClass

[Andreas Färber]

Am 27.04.2014 11:08, schrieb Marcel Apfelbaum:
> On Sat, 2014-04-26 at 00:30 +0200, Andreas Färber wrote:
>> Am 09.04.2014 19:34, schrieb Marcel Apfelbaum:
>>> Next steps:
>>>  - Replace QemuOpts queries by MachineState fields.
>>>  - Follow Paolo's suggestions to get rid of QEMUMachineInitArgs.
>>
>> Another next step will be re-evaluating the PC machines: If we let
>> pc-x.y inherit from either an abstract base type or from the latest PC
>> machine, then macro'ified copying of machine options can be replaced
>> with overriding the actually changing values.
> Are you referring to PC_COMPAT_xxx macros - compat_props?

Actually I rather meant PC_COMMON_MACHINE_OPTIONS,
PC_DEFAULT_MACHINE_OPTIONS, PC_I440FX_MACHINE_OPTIONS,
PC_Q35_MACHINE_OPTIONS et al. which are setting QEMUMachine fields, to
be converted to MachineClass fields. Rather than just have them
converted from ".foo = bar," to "dc->foo = bar;" I was thinking we might
put the common parts into a base type's *_class_init while at it, and
let the values be inherited via QOM rather than through repeated macro
usage.

Another more crazy thought would be whether we can construct a clever
type inheritance hierarchy so that the 1.7 is based off 2.0, etc.
That's about pc_compat_*() and pc_init_pci_*() / pc_q35_init_*() functions.

But you are of course right that we could/should at some point also
re-evaluate the rest of our PC macros, such as PC_COMPAT_xxx. :)

> If yes, I was thinking about approaching this in a not distant future.

Good. Maybe it makes sense to track these TODO items on a Wiki page,
such as http://wiki.qemu-project.org/Features/QOM/Machine?

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg