Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup

[Avi Kivity <avi@redhat.com>]

  On 08/23/2010 07:02 PM, Anthony Liguori wrote:
> On 08/23/2010 10:14 AM, Avi Kivity wrote:
>>  On 08/23/2010 05:47 PM, Anthony Liguori wrote:
>>>
>>>>>
>>>>> Devices can contain references to structs and objects.  If a 
>>>>> Device contains a reference to an object, the object should be 
>>>>> stored in a BusState which is a container of Devices.  Therefore, 
>>>>> the object should inherit from Device.
>>>>
>>>> I disagree.  It's up to the author to decide whether to split a 
>>>> Device into 1 or 15 objects.
>>>>
>>>> If one of the other objects is also a subclass of DeviceState, then 
>>>> you're probably violating that DeviceState's contract.  But that's 
>>>> a different (and trivial) matter.
>>>>
>>>> (side point: in C no objects have constructors and methods.  in C++ 
>>>> all objects have constructors and methods, even PODs)
>>>
>>> Things that inherit from DeviceState have ctors/dtors.  Things that 
>>> don't end up inventing their own and probably will do so poorly.
>>
>> you mean misimplement other_state_init(OtherState *) and 
>> other_state_destroy(OtherState *)?
>
> And hot plug, save/restore, properties, and all of the other things 
> that go along with qdev.
>
> Hot plug is a good example of how easy it is to screw this up by not 
> having the right hooks being propagated through the device model.

Come on now, this is all trivial.  If you get a qdev callback you just 
propagate it to all objects that need it.

Practically all non-trivial devices need to do it.  For example if you 
remove gpio from qdev, then a device that has an array of gpios will 
have un-embedded objects in its DeviceState.

Look at ivshmem.c with its non-embedded Peer objects.

-- 
error compiling committee.c: too many arguments to function