Re: [Qemu-devel] modelling omap_gpmc with the hierarchical memory API

[Avi Kivity <avi@redhat.com>]

On 08/03/2011 05:33 AM, Anthony Liguori wrote:
> On 08/02/2011 04:29 PM, Avi Kivity wrote:
>> On 08/03/2011 12:06 AM, Anthony Liguori wrote:
>>>
>>> The qdev level should be the common base that makes sense for *all*
>>> qdev devices. IRQ management does not belong in DeviceState because
>>> what you do for a simple LCD is not what you do for an MSI-X capable
>>> PCI device.
>>>
>>> This is what QOM properties tries to address. It should be possible to
>>> create a simple device, and register plugs/sockets for GPIO pins
>>> without pushing GPIO knowledge into the base class.
>>>
>>> In a QDev world, the right approach is to have a GpioDevice base class
>>> that implements this sort of logic for devices where it makes sense.
>>> That's what SysBusDevice sort of wants to be but it somehow ended up
>>> as yet another base class for everything.
>>>
>>
>> Doesn't this end up requiring multiple inheritance, and a ton of
>> boilerplate in addition?
>
> I don't see a ton of boiler plate nor do I see multiple inheritance. 
> Either you have devices that live on a bus that interact with other 
> devices via the bus interface or you have devices that interact 
> through Pin interactions.

If you have a GpioDevice to for devices/buses with gpio and a FooDevice 
for devices/buses with foo, how do you do a device that has both gpio 
and foo?

>
> But pushing everything into qdev is wrong.  This is a classic trap 
> with object oriented modelling.  Inheritance is supposed to model is-a 
> relationships, not "may-implement in some subclasses".  Not only does 
> it cause unnecessary bloat, it causes brittleness.
>
> What in the world would DeviceState::num_gpio_out mean for a PCI device?

Nothing.  It's always zero.

> It doesn't make sense at all which means it doesn't belong in 
> DeviceState.

What if the common subset is empty?

> Unless we're modelling the pin inputs and outputs for every device 
> that we possibly support..  But we're in for a world of hurt if that's 
> what our goals are.  Connecting PCI devices to their busses will be, 
> interesting, to say the least :-)

We use the high level functions to model address/data/irq/decode/etc. 
and gpio for the stuff that falls between the chairs.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.