Re: [Qemu-devel] [RFC] Plan for moving forward with QOM

[Paul Brook <paul_brook@mentor.com>]

> I also don't want the user to have to always make the decision about how to
> hook up IRQs for every single device because in a lot of circumstances,
> there's no point.

How else are we going to figure out how the IRQ lines are wired up?
 
> A basic premise for me is that simple things should be simple.  It
> shouldn't take a 800 line config file to create a PC.

IMO the PC is a bad example.  There's basically only one way things are ever 
wired up.  For other targets there is no standard reference design, and the 
hardware configuration is entirely a the whim of the vendor.

> >> But this entire use-case seems to be synthetic.  Do you have a real case
> >> where you would want to inherit twice from the same interface?
> > 
> > A GPIO controller (of which interrupt controllers are a subset).  We want
> > to expose and use many single-bit control line interfaces.
> 
> I don't see it but perhaps it's because I don't have sufficient
> imagination. Can you point me to a concrete example?

Pick pretty much an of them.  pl190 and pl061 are fairly standard examples.  
The former has 32 input pins to which other devices can link, and two output 
pins that can be linked to other output pins.  The latter has 8 inputs and 9 
outputs. The distinction between IRQ lines and GPIO output pins is a qdev wart 
that we should not repeat.  Both should be identified by name.

The contraints here are that each output pin will be linked to at most one 
input pin, and vice-versa.  Any output pin can by linked to any input pin.

> > I suppose pckbd.c is annother example.  This implements a pair of PS/2
> > serial busses.
> 
> I've dropped the notion of a "bus" in QOM.  They don't exist at all.
>
> The way this gets modeled in QOM is just to have a link<PS2Device> named
> kbd and a link<PS2Device> named aux.

This much I understand.

> pckbd implements PS2Bus and PS2Bus looks something like:
> 
> typedef struct PS2Bus {
>      Interface parent;
>      void (*set_irq)(PS2Bus *bus, PS2Device *dev, int level);
> } PS2Bus;

This is where I get a bit sketchy.  Is set_irq a pure virtual function that 
pckbk is expected to override?  And pckbd has to figure out which link this is 
based on the otherwise unnecessary dev argument?

> PS2Device looks like:
> 
> typedef struct PS2Device {
>      Device parent;
> 
>      PS2Bus *bus;
>      // ...
> } PS2Device;
> 
> The device just does:
> 
> void myfunc(PS2Keyboard *s)
> {
>     ps2_bus_set_irq(s->bus, PS2_DEVICE(s), 1);
> }

How does s->bus get set?

I guess you're expecting pckbd to do something like:

static void i8049_set_irq(PS2Bus *bus, PS2Device *dev, int level)
{
  Device *me = dynamic_cast<Device> bus;
  if (dev == get_dev_property(me, "kbd")) {
    kbd_update_kbd_irq(me, level);
  } else if (dev == get_dev_property(me, "aux")) {
    kbd_update_aux_irq(me, level);
  } else {
    abort();
  }
}

I guess that'll work, as long as both keyboard and mouse aren't implemented by 
the same device (which they might be for IRQ lines).

Paul