Re: [Qemu-devel] [PATCH 2/5] musicpal: qdevify musicpal-misc

[Andreas Färber]

Am 15.02.2013 16:14, schrieb Paolo Bonzini:
> Il 15/02/2013 14:48, Peter Maydell ha scritto:
>>>>>> If you prefer we could standardize on
>>>>>>   typedef struct {
>>>>>>       ParentClass parent;
>>>>>>   } FooClass;
>>>>>>
>>>>>> rather than typedef ParentClass FooClass;
>>>> It may need rework either way. Because aliasing via typedef gives
>>>> FooClass fields it will loose once it is turned into a real QOM class.
>>>> We had such an issue with i440fx in my PHB series, that's why I'm
>>>> sensitive to it. ;)
>> OK, so that seems like an argument for always defining the
>> empty-except-for-the-parentclass class struct, or does that
>> run into problems too?
> 
> I like the empty-except-for-parentclass.  OTOH, if you have no fields
> you will not use FOO_CLASS.  You will only use PARENT_CLASS, and those
> uses will be fine even after you start having a FooClass.
> 
> So, having no typedef and no _CLASS macros at all is simple and should
> be acceptable.
> 
> But if you have a typedef, you should a) make it a struct, b) add the
> _CLASS macros.

c) use it in TypeInfo, otherwise it's moot. :)

A related topic where having classes prepared may make sense is in
converting less-simple-than-SysBusDevice types to QOM realize. Device
Foo may need to call its parent's realize function then, so should save
it in its class, which it may not have yet.

However since this is IMO (compared to what other people have already
complained about) unnecessary boilerplate code, I'm more in favor of an
as-needed approach. I.e. if we don't need a struct, don't require to
define it nor macros to access it. But surely there's nothing wrong with
adding more structs/macros on a voluntary basis as long as they are
consistent.

Andreas

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