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
