On Tue, 2014-03-11 at 18:11 +0100, Andreas Färber wrote: > Hi Marcel, > > Am 11.03.2014 16:35, schrieb Marcel Apfelbaum: > > To be applied on top of: > > hw/boards: converted current_machine to be an instance of MachineClass > > Rebased for qom-next branch of Andrea's QOM tree. > > > > Patch 1: allows to assign QEMUMachine "automatically", > > and not only in vl.c (we need this in tests) > > Patch 2: converts "none-machine" to QOM > > Patch 3: Fixes qdev-global-props by adding the "none-machine" > > to the tree. > > > > Cc: Andreas Färber <afaer...@suse.de> > > > > Marcel Apfelbaum (3): > > hw/machine: move QEMUMachine assignment into the core machine > > hw/null-machine: Convert null machine to QOM > > tests/qdev-global-props: Manually add an instance of a QOM machine > > It seems I am to blame for most of the problems you are working around > now, so let's not be too shy to correct myself and make things easier on > us. ;) Well, I am on the "follow the rules" and not on "make the rules" stage yet, so I am trying to adapt... :)
> > I'd rather not take the class_base_init patch - for one class_init would > be more correct, Yes, it would be, I tried it, but it didn't work :( The code does not allow the derived class to use base's class_init function. This is the only reason I chose base_class_init. Do you know any other way to do it? (for my personal knowledge - it seems a very handy tool) > but for another I generally don't like putting such > requirements onto use of a base class. The null machine seems indeed low > hanging fruit for further cleanups - but can't we start by making > MachineClass used instead of QEMUMachine? Then we won't need to assign > mc->qemu_machine any more and can start dropping machine_none. This is indeed my next step after eliminating QemuOpts usage and replace it with QOM machine queries (should be quick, the patches were reviewed once already). Thanks, Marcel > > Regards, > Andreas >
