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
