Am 12.03.2012 10:38, schrieb Igor Mammedov:
> On 03/10/2012 03:28 AM, Andreas Färber wrote:
>> Reintroduce CPUState as QOM object: It's abstract and derived directly
>> from TYPE_OBJECT for compatibility with the user emulators.
>> The identifier CPUState avoids conflicts between CPU() and the struct.
>>
>> Introduce $(qom-twice-y) to build it separately for system and for user
>> emulators.
>>
>> Prepare a virtual reset method, (re)introduce cpu_reset() as wrapper.
>>
>> Signed-off-by: Andreas Färber<afaer...@suse.de>
>> Cc: Anthony Liguori<anth...@codemonkey.ws>
>> ---
>> Makefile.objs | 3 ++
>> configure | 1 +
>> include/qemu/cpu.h | 75
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> qom/Makefile | 1 +
>> qom/cpu.c | 58 ++++++++++++++++++++++++++++++++++++++++
>> 5 files changed, 138 insertions(+), 0 deletions(-)
>> create mode 100644 include/qemu/cpu.h
>> create mode 100644 qom/cpu.c
>> diff --git a/include/qemu/cpu.h b/include/qemu/cpu.h
>> new file mode 100644
>> index 0000000..4291279
>> --- /dev/null
>> +++ b/include/qemu/cpu.h
>> +/**
>> + * CPUClass:
>> + * @reset: Callback to reset the #CPU to its initial state.
>> + *
>> + * Represents a CPU family or model.
>> + */
>> +typedef struct CPUClass {
>> + /*< private>*/
>> + ObjectClass parent_class;
>> + /*< public>*/
>> +
>> + void (*reset)(CPUState *cpu);
> Why not use Object* as argument here?
In SysBusDeviceClass etc. we use the specific object type, too.
Obviously my CPU is the first "new" QOM type, so we can go different
ways if we want to. As long as it's a CPU-specific mechanism, using the
specific type avoids some casts.
> It will be easier to generalize later qdev code and not make special
> case when
> adding cpus.
I never heard anyone wanting to generalize reset so far. I don't think
it belongs into Object at least. Maybe DeviceState. Anthony? Paolo?
> BTW how we are going to generalize qdev and make its infrastructure
> available
> to other types except of DEVICE_TYPE.
> Maybe we should introduce some (abstract) base class (or interface) for
> basic
> device that will define methods like reset, realize, unrealize and use
> it in
> qdev code instead of DEVICE_TYPE?
I thought Anthony wanted to do realize/unrealize and "realized" property
in Object.
For SH4 I worked around that with my own sh7750_realize() function. This
series is taking much too long to move forward (the QOM "steam" seems to
be gone?) and I'm worried that introducing much more basic
infrastructure will make review and applying even slower, cf.
object_class_foreach_ordered()/_get_list().
Thanks for reviewing so far,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
