qemu-devel
[Top][All Lists]
Advanced

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

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup
Date: Tue, 24 Aug 2010 12:51:55 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1

 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




reply via email to

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