Re: [Qemu-devel] [PATCH 1/3] qdev-ify isa pic

[Paul Brook <paul@codesourcery.com>]

On Wednesday 10 June 2009, Gerd Hoffmann wrote:
> On 06/10/09 11:43, Filip Navara wrote:
> > On Wed, Jun 10, 2009 at 9:32 AM, Gerd Hoffmann<kraxel@redhat.com>  wrote:
> > [snip]>
> >
> >> In general I think we should handle as much as possible at DeviceState /
> >> DeviceInfo level.  Stuff which devices commonly have should live there:
> >>   IRQs, mmio, ioports, ... in DeviceState.  name, init and other generic
> >> callbacks, ... in DeviceInfo.
> >>
> >> The bus structs should only hold stuff which is actually specific to
> >> that bus.  That is probably almost nothing for sysbus.  i2c has the xfer
> >> callbacks in I2CSlaveInfo.  Likewise pci can have the config space
> >> read/write callbacks in PCIDeviceInfo.
> >
> > This is definitely based on wrong assumptions. I've GPIO devices
> > modelled on top of qdev and they don't know anything about IRQs, MMIO
> > or stuff like that. All they know about is that there are few in/out
> > GPIO pins, which are connected to the GPIO controller in the emulated
> > microcontroller.
>
> Sure, not every device has IRQs.  Nevertheless almost every bus out
> there supports IRQs.  Thus it is IMHO pointless to have a common thing
> duplicated in each end every bus implementation, it should be in the
> most basic type instead.

My initial implementation tried to push IRQ and MMIO handling into 
DeviceState, and it didn't fit well.

PCI v.s. SysBus is a good example here.  Both have IRQs and MMIO regions. 
However the way these are configured and exposed to devices is very different. 
In practice you end up needing per-bus wrappers/hooks, and there's very little 
useful common code.

For things that are truly bus agnostic (or independent of the primary bus, 
e.g. GPIO pins) pushing up to the qdev level makes sense.

Paul