qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH V3 0/5] remove QEMUMachine indirection from MachineClass
Date: Sun, 27 Apr 2014 12:08:11 +0300

On Sat, 2014-04-26 at 00:30 +0200, Andreas Färber wrote:
> Am 09.04.2014 19:34, schrieb Marcel Apfelbaum:
> > 
> > This is a continuation of 'QEMU Machine as QOM object' effort.
> > The scope of this series is to allow machine QOM-ification
> > of all machines gradually, by removing the need for QEMUMachine 
> > registration through vl.c .
> > 
> > Now we will have 2 paths:
> > 1. Non QOM-ified machines will be converted to QOM on the fly
> >    in vl.c by qemu machine registration.
> > 2. QOM-ified machines will behave as regular QOM classes setting
> >    MachineClass fields in class_init.
> >    - Patch 4/5 demonstrates this.
> > 
> > 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?
If yes, I was thinking about approaching this in a not distant future. 

> 
> Both Igor's memory hot-add series and Don's Xen memory series would
> benefit IIRC. Who volunteers for a shallow or less shallow conversion?
I'll have a look on their series to understand how they are related.
I think Igor already made a PC-MACHINE type.

> 
> Also, how do we proceed with getting rid of registration path 1
> elsewhere? If we leave it around, experience shows that people will copy
> the wrong of two possible ways for implementing new things.
Well, the problem here is not the code modifications, which are mechanical,
but the testing that everything still works.
I propose that I'll make the changes, not as a big patch,
but every week a subsystem, and the maintainer of the subsystem
will test and give the OK.

Seems reasonable?
Thanks,
Marcel  

> 
> > Marcel Apfelbaum (5):
> >   hw/boards.h: remove obsoleted field from QEMUMachine
> >   vl.c: copy QEMUMachine's fields to MachineClass
> >   vl.c: Replace QEMUMachine with MachineClass in QEMUMachineInitArgs
> >   machine: replace QEMUMachine by MachineClass in accelerator
> >     configuration
> >   machine: remove QEMUMachine indirection from MachineClass
> 
> Thanks a lot, applied (with changes) to qom-next:
> https://github.com/afaerber/qemu-cpu/commits/qom-next
> 
> Cheers,
> Andreas
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]