qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v1 0/7] QOM Super class access


From: Hu Tao
Subject: Re: [Qemu-devel] [RFC PATCH v1 0/7] QOM Super class access
Date: Wed, 19 Jun 2013 09:44:57 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Jun 18, 2013 at 12:41:29PM +0200, Andreas Färber wrote:
> Am 18.06.2013 12:23, schrieb Michael S. Tsirkin:
> > On Tue, Jun 18, 2013 at 07:43:11PM +1000, address@hidden wrote:
> >> From: Peter Crosthwaite <address@hidden>
> >>
> >>
> >> 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
> > 
> > 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?
> 
> 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))

This can simply be object_class_get_parent_by_type(), then we don't
have to define a macro for it everytime.

> 
> and then use
> 
> DEVICE_CLASS(ARM_CPU_SUPER_CLASS())
> or
> CPU_CLASS(ARM_CPU_SUPER_CLASS())
> 
> as needed. What do you think?
> 
> Andreas
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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