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

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/15/2011 03:28 PM, Paul Brook wrote:
>> There is a second class of "user" that is doing very sophisticated things
>> and cares about this information.  But this sophisticated user (i.e.
>> libvirt) wants to be able to probe QEMU to understand what features
>> are probably available because it very likely is evolving just as quickly as
>> QEMU is.
>
> I disagree.  Maybe this is because you're coming from the PC/Linux world where
> all hardware is basically the same.
>
> In the embedded world there are many more vastly different machines.  And some
> of those have several similar but different enough to matter variants.
> There's a good chance the guest OS needs exactly the right one.
>
> Take the Stellaris boards as an example.  We currently implement two boards.
> There are well over a hundred variants in this SoC family.  A good proportion
> of these chips will be used in projects that include a custom PCB design.
> There are at least three different reference boards for the LM3S6965 alone.
> This is not unusual.
>
> I really don't want to have to teach qemu about hunderds of different SoCs
> connected to thousands of different "motherboards", most of which we'll never
> even know about.  I'd like for users to be able to create their own hardware
> config without having to track qemu implementation details.

Yes, we're on the same page here.  One of my primary objectives in this 
refactoring is to eliminate the notion of a "machine" as anything that is at all 
special.  I want the ability to have a "pc" device that has (via composition) 
all of the normal PC components via composition.

But don't confuse flexibility with compatibility.  If you're hooking up IRQ 
lines to make a custom SOC, then I don't think you're the type of user that 
can't handle the fact that we may change whether the PIIX inherits from or 
implements it's bus in a new version.

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.

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.

>> You're advocating only connecting properties to properties, and never an
>> object to a property?  I think that's needlessly complicated.  In the vast
>> majority of cases, you just case about saying "connect this
>> CharDriverState to this Serial device".  We should make it much more
>> complicated than that.
>
> Yes, that's what I'm saying.  I'm finding it hard to believe that more than
> one link being stateful is such an exceptional case.
>
> Am I right in thinking that you're effectively implementing multiple
> inheritance via properties?  If so I guess works around the single-inheritance
> limitation in many cases.

No.  Properties are strictly for composition.  A lot of times people advocate 
using composition instead of inheritance.  In fact, it's covered extensively in 
"Effective C++" if you're interested.

>> 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?

I very much want to avoid over engineering things so I would prefer to only 
worry problems we know we need to solve.

Honestly, the details we're discussing right now are minor and it wouldn't be 
that hard to change the way inheritance works if we wanted to support true MI.

> 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.

pckbd implements PS2Bus and PS2Bus looks something like:

typedef struct PS2Bus {
     Interface parent;
     void (*set_irq)(PS2Bus *bus, PS2Device *dev, int level);
} PS2Bus;

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);
}

You could call bus "controller", "other-device", "fubar", or whatever.

> Currently we don't model these and use hardcoded callbacks when
> creating the keyboard/mouse devices.

Yes, it sucks, and once my qom-next tree is merged I'll fix this so it works as 
above and you can instantiate a PS2Mouse and set the i8054.aux property to the 
mouse device that you create.

> Once modelled properly I'd expect a
> board to be able to replace either with a third [as yet unimplemented] PS/2
> device.

The i8042 is not as generic as you think, but yes, if you made a PS/2 AUX 
compatible device (perhaps a tablet or something), you could just drop it in.

> Any of the those devices should also be usable with the single-port
> ARM PL050 controller.

Yup, it would all work out very nicely.  PL050 would implement PS2Bus and have 
just a single link<PS2Device>.

Regards,

Anthony Liguori

>
> Paul
>