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

[Avi Kivity]

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.