QOM Super class access

From: Peter Crosthwaite <[email protected]>

QOM automatically inherits class and instance size from the parent class. No need to redefine as the same value as the parent.

CC [email protected]

Signed-off-by Peter Crosthwaite <[email protected]>

---

 target-arm/cpu.c | 2 --
 1 file changed, 2 deletions(-)

target-arm/cpu.c +0 -2

index 496a59f..47a21ec 100644
@@ -821,9 +821,7 @@ static void cpu_register(const ARMCPUInfo *info)
 {
     TypeInfo type_info = {
         .parent = TYPE_ARM_CPU,
-        .instance_size = sizeof(ARMCPU),
         .instance_init = info->initfn,
-        .class_size = sizeof(ARMCPUClass),
         .class_init = info->class_init,
     };
 

From: Peter Crosthwaite <[email protected]>

Add macros DEVICE_SUPER_CLASS and DEVICE_GET_SUPER_CLASS. These are the similar to their respective non SUPER versions, except instead of returning the class object for the concrete class, they return their parent classes implementation (usually some form of abstract class).

Signed-off-by Peter Crosthwaite <[email protected]>

---

 include/hw/qdev-core.h | 4 ++++
 1 file changed, 4 insertions(+)

include/hw/qdev-core.h +0 -0

index 7fbffcb..96647c4 100644

include/hw/qdev-core.h +0 -0

 typedef int (*qdev_initfn)(DeviceState *dev);
 typedef int (*qdev_event)(DeviceState *dev);

Signature · 1 line

1.8.3.rc1.44.gb387c77.dirty

From: Peter Crosthwaite <[email protected]>

This series enables QOM super class access and demostrates some usages. Replaces the save->override->call via FooClass technique, to reduce some of the boiler plate in recently fully QOMified devices.

Applied the change to ARM CPU, MB CPU and some of Andreas's recently QOMified i386 devices, all which have the save->override->call issue. ARMCPU I've done a brief test on and seems to work.

ARM CPU was particularly difficult, as it has 3 layers of heirachy, where a non-concrete class (TYPE_ARM_CPU) need to super class itself (to TYPE_CPU). This sees the need for super-classers to specify their expected base class level. See patches for illustration.

The main future work to the series is to apply the change pattern to the reset of the tree

Peter Crosthwaite (7):
target-arm/cpu.c: delete un-needed instance/class sizes
qom: Add super class accessor
qdev-core: Introduce DEVICE super class cast macros qom/cpu: Introduce CPU super class cast macros
target-arm: Remove ARMCPUClass
target-microblaze: Remove MicroblazeCPUClass

i8254: Remove [KVM]PITClass

 hw/i386/kvm/i8254.c         | 17 ++---------------
 hw/timer/i8254.c            | 16 ++--------------
 include/hw/qdev-core.h      |  4 ++++
 include/qom/cpu.h           |  4 ++++
 include/qom/object.h        | 18 ++++++++++++++++++
 qom/object.c                | 15 +++++++++++++++
 target-arm/cpu-qom.h        | 20 --------------------
 target-arm/cpu.c            | 16 +++++-----------
 target-microblaze/cpu-qom.h | 20 --------------------
 target-microblaze/cpu.c     | 13 ++++---------
 10 files changed, 54 insertions(+), 89 deletions(-)

Hi Peter,

Am 18.06.2013 11:43, schrieb [email protected]:

Quoted 7 lines

From: Peter Crosthwaite <[email protected]>

This series enables QOM super class access and demostrates some usages. Replaces the save->override->call via FooClass technique, to reduce some of the boiler plate in recently fully QOMified devices.

Quoted 8 lines

Applied the change to ARM CPU, MB CPU and some of Andreas's recently QOMified i386 devices, all which have the save->override->call issue. ARMCPU I've done a brief test on and seems to work.

ARM CPU was particularly difficult, as it has 3 layers of heirachy, where a non-concrete class (TYPE_ARM_CPU) need to super class itself (to TYPE_CPU). This sees the need for super-classers to specify their expected base class level. See patches for illustration.

Thanks for experimenting with this. Anthony had asked to give him more review time on my virtio series before choosing a path to pursue there.

Quoted 11 lines

The main future work to the series is to apply the change pattern to the reset of the tree

Peter Crosthwaite (7):
target-arm/cpu.c: delete un-needed instance/class sizes
qom: Add super class accessor
qdev-core: Introduce DEVICE super class cast macros qom/cpu: Introduce CPU super class cast macros
target-arm: Remove ARMCPUClass
target-microblaze: Remove MicroblazeCPUClass

Still need to review the new macros in-depth, but I'm skeptical about removing *CPUClass'es while CPUState conversions are still ongoing ...

Quoted 1 line

i8254: Remove [KVM]PITClass

... whereas this one was purely introduced for QOM realize, so OK.

Also the subjects are a bit misleading, suggest something like "...: Use super class macro".

Cheers,
Andreas

Quoted 11 lines

 hw/i386/kvm/i8254.c         | 17 ++---------------
 hw/timer/i8254.c            | 16 ++--------------
 include/hw/qdev-core.h      |  4 ++++
 include/qom/cpu.h           |  4 ++++
 include/qom/object.h        | 18 ++++++++++++++++++
 qom/object.c                | 15 +++++++++++++++
 target-arm/cpu-qom.h        | 20 --------------------
 target-arm/cpu.c            | 16 +++++-----------
 target-microblaze/cpu-qom.h | 20 --------------------
 target-microblaze/cpu.c     | 13 ++++---------
 10 files changed, 54 insertions(+), 89 deletions(-)

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

From: Peter Crosthwaite <[email protected]>

This series enables QOM super class access and demostrates some usages. Replaces the save->override->call via FooClass technique, to reduce some of the boiler plate in recently fully QOMified devices.

Applied the change to ARM CPU, MB CPU and some of Andreas's recently QOMified i386 devices, all which have the save->override->call issue. ARMCPU I've done a brief test on and seems to work.

ARM CPU was particularly difficult, as it has 3 layers of heirachy, where a non-concrete class (TYPE_ARM_CPU) need to super class itself (to TYPE_CPU). This sees the need for super-classers to specify their expected base class level. See patches for illustration.

The main future work to the series is to apply the change pattern to the reset of the tree

Peter Crosthwaite (7):
target-arm/cpu.c: delete un-needed instance/class sizes
qom: Add super class accessor
qdev-core: Introduce DEVICE super class cast macros qom/cpu: Introduce CPU super class cast macros
target-arm: Remove ARMCPUClass
target-microblaze: Remove MicroblazeCPUClass
i8254: Remove [KVM]PITClass

 hw/i386/kvm/i8254.c         | 17 ++---------------
 hw/timer/i8254.c            | 16 ++--------------
 include/hw/qdev-core.h      |  4 ++++
 include/qom/cpu.h           |  4 ++++
 include/qom/object.h        | 18 ++++++++++++++++++
 qom/object.c                | 15 +++++++++++++++
 target-arm/cpu-qom.h        | 20 --------------------
 target-arm/cpu.c            | 16 +++++-----------
 target-microblaze/cpu-qom.h | 20 --------------------
 target-microblaze/cpu.c     | 13 ++++---------
 10 files changed, 54 insertions(+), 89 deletions(-)

Signature · 1 line

1.8.3.rc1.44.gb387c77.dirty

Quoted 16 lines · On Tue, Jun 18, 2013 at 07:43:11PM +1000, [email protected] wrote:

From: Peter Crosthwaite <[email protected]>

This series enables QOM super class access and demostrates some usages. Replaces the save->override->call via FooClass technique, to reduce some of the boiler plate in recently fully QOMified devices.

Applied the change to ARM CPU, MB CPU and some of Andreas's recently QOMified i386 devices, all which have the save->override->call issue. ARMCPU I've done a brief test on and seems to work.

ARM CPU was particularly difficult, as it has 3 layers of heirachy, where a non-concrete class (TYPE_ARM_CPU) need to super class itself (to TYPE_CPU). This sees the need for super-classers to specify their expected base class level. See patches for illustration.

Quoted 2 lines

The main future work to the series is to apply the change pattern to the reset of the tree

Looks good to me overall.
Some nits:
- Super is an immediate parent in java and python.

- One of the design points of QOM is that it let you ignore which class is a parent and which is a child. All casts look the same.

So, why do we need the new APIs with _SUPER?

What's wrong with simple
object_class_by_name()
and casting to that?

Quoted 25 lines

Peter Crosthwaite (7):
target-arm/cpu.c: delete un-needed instance/class sizes
qom: Add super class accessor
qdev-core: Introduce DEVICE super class cast macros qom/cpu: Introduce CPU super class cast macros
target-arm: Remove ARMCPUClass
target-microblaze: Remove MicroblazeCPUClass
i8254: Remove [KVM]PITClass

 hw/i386/kvm/i8254.c         | 17 ++---------------
 hw/timer/i8254.c            | 16 ++--------------
 include/hw/qdev-core.h      |  4 ++++
 include/qom/cpu.h           |  4 ++++
 include/qom/object.h        | 18 ++++++++++++++++++
 qom/object.c                | 15 +++++++++++++++
 target-arm/cpu-qom.h        | 20 --------------------
 target-arm/cpu.c            | 16 +++++-----------
 target-microblaze/cpu-qom.h | 20 --------------------
 target-microblaze/cpu.c     | 13 ++++---------
 10 files changed, 54 insertions(+), 89 deletions(-)

--
1.8.3.rc1.44.gb387c77.dirty

Hi Michael,

Quoted 17 lines · Michael S. Tsirkin

Quoted 16 lines · On Tue, Jun 18, 2013 at 07:43:11PM +1000, [email protected] wrote:

From: Peter Crosthwaite <[email protected]>

This series enables QOM super class access and demostrates some usages. Replaces the save->override->call via FooClass technique, to reduce some of the boiler plate in recently fully QOMified devices.

Applied the change to ARM CPU, MB CPU and some of Andreas's recently QOMified i386 devices, all which have the save->override->call issue. ARMCPU I've done a brief test on and seems to work.

ARM CPU was particularly difficult, as it has 3 layers of heirachy, where a non-concrete class (TYPE_ARM_CPU) need to super class itself (to TYPE_CPU). This sees the need for super-classers to specify their expected base class level. See patches for illustration.

Quoted 6 lines

Quoted 2 lines

The main future work to the series is to apply the change pattern to the reset of the tree

Looks good to me overall.
Some nits:
- Super is an immediate parent in java and python.

s/Super/parent might be the go. But it is designed to work like py/java. Its the immediate parent of the specified level, and it is analogous to the java super.

Quoted 5 lines

- One of the design points of QOM is that it let you ignore which class is a parent and which is a child. All casts look the same.

So, why do we need the new APIs with _SUPER?

The SUPER APIs have a nice consistent appearance with the GET_CLASS and FOO_CLASS APIs and they are likely to live alongside each other in QOM fns.

Quoted 4 lines

What's wrong with simple
object_class_by_name()
and casting to that?

There a performance consequence - object_class_by_name is a lookup, whereas this approach is able to just walk the pointer through the inheritance heirachy till it hits.

Tying it to an object also brings
into play the possibility of a cast cache should that be needed.

Thanks for the review.

Regards,
Peter

Quoted 26 lines

Quoted 25 lines

Peter Crosthwaite (7):
target-arm/cpu.c: delete un-needed instance/class sizes
qom: Add super class accessor
qdev-core: Introduce DEVICE super class cast macros qom/cpu: Introduce CPU super class cast macros
target-arm: Remove ARMCPUClass
target-microblaze: Remove MicroblazeCPUClass
i8254: Remove [KVM]PITClass

 hw/i386/kvm/i8254.c         | 17 ++---------------
 hw/timer/i8254.c            | 16 ++--------------
 include/hw/qdev-core.h      |  4 ++++
 include/qom/cpu.h           |  4 ++++
 include/qom/object.h        | 18 ++++++++++++++++++
 qom/object.c                | 15 +++++++++++++++
 target-arm/cpu-qom.h        | 20 --------------------
 target-arm/cpu.c            | 16 +++++-----------
 target-microblaze/cpu-qom.h | 20 --------------------
 target-microblaze/cpu.c     | 13 ++++---------
 10 files changed, 54 insertions(+), 89 deletions(-)

--
1.8.3.rc1.44.gb387c77.dirty

Quoted 41 lines · Peter Crosthwaite

Hi Michael,

Quoted 17 lines · Michael S. Tsirkin

Quoted 16 lines · On Tue, Jun 18, 2013 at 07:43:11PM +1000, [email protected] wrote:

From: Peter Crosthwaite <[email protected]>

This series enables QOM super class access and demostrates some usages. Replaces the save->override->call via FooClass technique, to reduce some of the boiler plate in recently fully QOMified devices.

Applied the change to ARM CPU, MB CPU and some of Andreas's recently QOMified i386 devices, all which have the save->override->call issue. ARMCPU I've done a brief test on and seems to work.

ARM CPU was particularly difficult, as it has 3 layers of heirachy, where a non-concrete class (TYPE_ARM_CPU) need to super class itself (to TYPE_CPU). This sees the need for super-classers to specify their expected base class level. See patches for illustration.

Quoted 6 lines

Quoted 2 lines

The main future work to the series is to apply the change pattern to the reset of the tree

Looks good to me overall.
Some nits:
- Super is an immediate parent in java and python.

s/Super/parent might be the go. But it is designed to work like py/java. Its the immediate parent of the specified level, and it is analogous to the java super.

Quoted 5 lines

- One of the design points of QOM is that it let you ignore which class is a parent and which is a child. All casts look the same.

So, why do we need the new APIs with _SUPER?

The SUPER APIs have a nice consistent appearance with the GET_CLASS and FOO_CLASS APIs and they are likely to live alongside each other in QOM fns.

Quoted 8 lines

Quoted 4 lines

What's wrong with simple
object_class_by_name()
and casting to that?

There a performance consequence - object_class_by_name is a lookup, whereas this approach is able to just walk the pointer through the inheritance heirachy till it hits.

None of these uses has a chance to be at all performance sensitive.

Quoted 2 lines

Tying it to an object also brings
into play the possibility of a cast cache should that be needed.

Doesn't make sense to me. This is object construction, how many classes do you expect there to be so this would affect qemu startup speed noticeably? 1000000?

Quoted 31 lines

Thanks for the review.

Regards,
Peter

Quoted 26 lines

Quoted 25 lines

Peter Crosthwaite (7):
target-arm/cpu.c: delete un-needed instance/class sizes
qom: Add super class accessor
qdev-core: Introduce DEVICE super class cast macros qom/cpu: Introduce CPU super class cast macros
target-arm: Remove ARMCPUClass
target-microblaze: Remove MicroblazeCPUClass
i8254: Remove [KVM]PITClass

 hw/i386/kvm/i8254.c         | 17 ++---------------
 hw/timer/i8254.c            | 16 ++--------------
 include/hw/qdev-core.h      |  4 ++++
 include/qom/cpu.h           |  4 ++++
 include/qom/object.h        | 18 ++++++++++++++++++
 qom/object.c                | 15 +++++++++++++++
 target-arm/cpu-qom.h        | 20 --------------------
 target-arm/cpu.c            | 16 +++++-----------
 target-microblaze/cpu-qom.h | 20 --------------------
 target-microblaze/cpu.c     | 13 ++++---------
 10 files changed, 54 insertions(+), 89 deletions(-)

--
1.8.3.rc1.44.gb387c77.dirty

HI Michael,

Quoted 55 lines · Michael S. Tsirkin

Quoted 41 lines · Peter Crosthwaite

Hi Michael,

Quoted 17 lines · Michael S. Tsirkin

Quoted 16 lines · On Tue, Jun 18, 2013 at 07:43:11PM +1000, [email protected] wrote:

From: Peter Crosthwaite <[email protected]>

This series enables QOM super class access and demostrates some usages. Replaces the save->override->call via FooClass technique, to reduce some of the boiler plate in recently fully QOMified devices.

Applied the change to ARM CPU, MB CPU and some of Andreas's recently QOMified i386 devices, all which have the save->override->call issue. ARMCPU I've done a brief test on and seems to work.

ARM CPU was particularly difficult, as it has 3 layers of heirachy, where a non-concrete class (TYPE_ARM_CPU) need to super class itself (to TYPE_CPU). This sees the need for super-classers to specify their expected base class level. See patches for illustration.

Quoted 6 lines

Quoted 2 lines

The main future work to the series is to apply the change pattern to the reset of the tree

Looks good to me overall.
Some nits:
- Super is an immediate parent in java and python.

s/Super/parent might be the go. But it is designed to work like py/java. Its the immediate parent of the specified level, and it is analogous to the java super.

Quoted 5 lines

- One of the design points of QOM is that it let you ignore which class is a parent and which is a child. All casts look the same.

So, why do we need the new APIs with _SUPER?

The SUPER APIs have a nice consistent appearance with the GET_CLASS and FOO_CLASS APIs and they are likely to live alongside each other in QOM fns.

Quoted 8 lines

Quoted 4 lines

What's wrong with simple
object_class_by_name()
and casting to that?

There a performance consequence - object_class_by_name is a lookup, whereas this approach is able to just walk the pointer through the inheritance heirachy till it hits.

None of these uses has a chance to be at all performance sensitive.

Quoted 8 lines

Quoted 2 lines

Tying it to an object also brings
into play the possibility of a cast cache should that be needed.

Doesn't make sense to me. This is object construction, how many classes do you expect there to be so this would affect qemu startup speed noticeably? 1000000?

The idea is this is usable in any overridden QOM fn. True, our only current need for such a system is realize, reset and unrealize, but that could change in the future with more sophistaicated QOM setups where hot-path run time functionality has QOM heirachy as well.

Regards,
Peter

Quoted 32 lines

Quoted 31 lines

Thanks for the review.

Regards,
Peter

Quoted 26 lines

Quoted 25 lines

Peter Crosthwaite (7):
target-arm/cpu.c: delete un-needed instance/class sizes
qom: Add super class accessor
qdev-core: Introduce DEVICE super class cast macros qom/cpu: Introduce CPU super class cast macros
target-arm: Remove ARMCPUClass
target-microblaze: Remove MicroblazeCPUClass
i8254: Remove [KVM]PITClass

 hw/i386/kvm/i8254.c         | 17 ++---------------
 hw/timer/i8254.c            | 16 ++--------------
 include/hw/qdev-core.h      |  4 ++++
 include/qom/cpu.h           |  4 ++++
 include/qom/object.h        | 18 ++++++++++++++++++
 qom/object.c                | 15 +++++++++++++++
 target-arm/cpu-qom.h        | 20 --------------------
 target-arm/cpu.c            | 16 +++++-----------
 target-microblaze/cpu-qom.h | 20 --------------------
 target-microblaze/cpu.c     | 13 ++++---------
 10 files changed, 54 insertions(+), 89 deletions(-)

--
1.8.3.rc1.44.gb387c77.dirty

Quoted 41 lines

Hi Michael,

Quoted 17 lines · Michael S. Tsirkin

Quoted 16 lines · On Tue, Jun 18, 2013 at 07:43:11PM +1000, [email protected] wrote:

From: Peter Crosthwaite <[email protected]>

This series enables QOM super class access and demostrates some usages. Replaces the save->override->call via FooClass technique, to reduce some of the boiler plate in recently fully QOMified devices.

Applied the change to ARM CPU, MB CPU and some of Andreas's recently QOMified i386 devices, all which have the save->override->call issue. ARMCPU I've done a brief test on and seems to work.

ARM CPU was particularly difficult, as it has 3 layers of heirachy, where a non-concrete class (TYPE_ARM_CPU) need to super class itself (to TYPE_CPU). This sees the need for super-classers to specify their expected base class level. See patches for illustration.

Quoted 6 lines

Quoted 2 lines

The main future work to the series is to apply the change pattern to the reset of the tree

Looks good to me overall.
Some nits:
- Super is an immediate parent in java and python.

s/Super/parent might be the go. But it is designed to work like py/java. Its the immediate parent of the specified level, and it is analogous to the java super.

Quoted 5 lines

- One of the design points of QOM is that it let you ignore which class is a parent and which is a child. All casts look the same.

So, why do we need the new APIs with _SUPER?

The SUPER APIs have a nice consistent appearance with the GET_CLASS and FOO_CLASS APIs and they are likely to live alongside each other in QOM fns.

Quoted 8 lines

Quoted 4 lines

What's wrong with simple
object_class_by_name()
and casting to that?

There a performance consequence - object_class_by_name is a lookup, whereas this approach is able to just walk the pointer through the inheritance heirachy till it hits.

None of these uses has a chance to be at all performance sensitive.

Quoted 2 lines

Tying it to an object also brings
into play the possibility of a cast cache should that be needed.

Doesn't make sense to me. This is object construction, how many classes do you expect there to be so this would affect qemu startup speed noticeably? 1000000?

Quoted 32 lines

Thanks for the review.

Regards,
Peter

Quoted 26 lines

Quoted 25 lines

Peter Crosthwaite (7):
target-arm/cpu.c: delete un-needed instance/class sizes
qom: Add super class accessor
qdev-core: Introduce DEVICE super class cast macros qom/cpu: Introduce CPU super class cast macros
target-arm: Remove ARMCPUClass
target-microblaze: Remove MicroblazeCPUClass
i8254: Remove [KVM]PITClass

 hw/i386/kvm/i8254.c         | 17 ++---------------
 hw/timer/i8254.c            | 16 ++--------------
 include/hw/qdev-core.h      |  4 ++++
 include/qom/cpu.h           |  4 ++++
 include/qom/object.h        | 18 ++++++++++++++++++
 qom/object.c                | 15 +++++++++++++++
 target-arm/cpu-qom.h        | 20 --------------------
 target-arm/cpu.c            | 16 +++++-----------
 target-microblaze/cpu-qom.h | 20 --------------------
 target-microblaze/cpu.c     | 13 ++++---------
 10 files changed, 54 insertions(+), 89 deletions(-)

--
1.8.3.rc1.44.gb387c77.dirty

Quoted 11 lines

From: Peter Crosthwaite <[email protected]>

This series enables QOM super class access and demostrates some usages. Replaces the save->override->call via FooClass technique, to reduce some of the boiler plate in recently fully QOMified devices.

Applied the change to ARM CPU, MB CPU and some of Andreas's recently QOMified i386 devices, all which have the save->override->call issue. ARMCPU I've done a brief test on and seems to work.

Quoted 7 lines

ARM CPU was particularly difficult, as it has 3 layers of heirachy, where a non-concrete class (TYPE_ARM_CPU) need to super class itself (to TYPE_CPU). This sees the need for super-classers to specify their expected base class level. See patches for illustration.

The main future work to the series is to apply the change pattern to the reset of the tree

Looks good to me overall.
Some nits:
- Super is an immediate parent in java and python.
- One of the design points of QOM is that it let you ignore which class is a parent and which is a child. All casts look the same.

So, why do we need the new APIs with _SUPER?
What's wrong with simple
object_class_by_name()
and casting to that?

Am 18.06.2013 12:23, schrieb Michael S. Tsirkin:

Quoted 27 lines · On Tue, Jun 18, 2013 at 07:43:11PM +1000, [email protected] wrote:

Quoted 11 lines

From: Peter Crosthwaite <[email protected]>

This series enables QOM super class access and demostrates some usages. Replaces the save->override->call via FooClass technique, to reduce some of the boiler plate in recently fully QOMified devices.

Applied the change to ARM CPU, MB CPU and some of Andreas's recently QOMified i386 devices, all which have the save->override->call issue. ARMCPU I've done a brief test on and seems to work.

Quoted 7 lines

ARM CPU was particularly difficult, as it has 3 layers of heirachy, where a non-concrete class (TYPE_ARM_CPU) need to super class itself (to TYPE_CPU). This sees the need for super-classers to specify their expected base class level. See patches for illustration.

The main future work to the series is to apply the change pattern to the reset of the tree

Looks good to me overall.
Some nits:
- Super is an immediate parent in java and python.
- One of the design points of QOM is that it let you ignore which class is a parent and which is a child. All casts look the same.

Quoted 4 lines

So, why do we need the new APIs with _SUPER?
What's wrong with simple
object_class_by_name()
and casting to that?

I guess the idea was to avoid open-coding that multiple times, but I think I would then prefer something more local like

#define ARM_CPU_SUPER_CLASS() \
object_class_get_parent(object_class_by_name(TYPE_ARM_CPU))

and then use

DEVICE_CLASS(ARM_CPU_SUPER_CLASS())
or
CPU_CLASS(ARM_CPU_SUPER_CLASS())

as needed. What do you think?

Andreas

Signature · 2 lines

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

Am 18.06.2013 12:23, schrieb Michael S. Tsirkin:

Quoted 27 lines · On Tue, Jun 18, 2013 at 07:43:11PM +1000, [email protected] wrote:

Quoted 11 lines

From: Peter Crosthwaite <[email protected]>

This series enables QOM super class access and demostrates some usages. Replaces the save->override->call via FooClass technique, to reduce some of the boiler plate in recently fully QOMified devices.

Applied the change to ARM CPU, MB CPU and some of Andreas's recently QOMified i386 devices, all which have the save->override->call issue. ARMCPU I've done a brief test on and seems to work.

Quoted 7 lines

ARM CPU was particularly difficult, as it has 3 layers of heirachy, where a non-concrete class (TYPE_ARM_CPU) need to super class itself (to TYPE_CPU). This sees the need for super-classers to specify their expected base class level. See patches for illustration.

The main future work to the series is to apply the change pattern to the reset of the tree

Looks good to me overall.
Some nits:
- Super is an immediate parent in java and python.
- One of the design points of QOM is that it let you ignore which class is a parent and which is a child. All casts look the same.

Quoted 4 lines

So, why do we need the new APIs with _SUPER?
What's wrong with simple
object_class_by_name()
and casting to that?

I guess the idea was to avoid open-coding that multiple times, but I think I would then prefer something more local like

#define ARM_CPU_SUPER_CLASS() \
object_class_get_parent(object_class_by_name(TYPE_ARM_CPU))

and then use

DEVICE_CLASS(ARM_CPU_SUPER_CLASS())
or
CPU_CLASS(ARM_CPU_SUPER_CLASS())

as needed. What do you think?

Andreas

Signature · 2 lines

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