qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Brook
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Tue, 13 Dec 2011 20:36:00 +0000
User-agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )

> > That still leaves both PCIDevice and SysBusDevice state.  The i440fx
> > is a fairly simple device, but more complex bridges have additional state
> > that needs to be accessible from both the PCI and SysBus interfaces.
> 
> SysBus is so badly abused today I think we would have to reevaluate what to
> do with it once we fix up some of the devices that make use of it.

Ok, so i440fx might not need any state on the SysBus side (or whatever the PC 
mutation of SysBus ends up being).  However I'm pretty sure at some of our 
devices will hit this issue.

It also means the cpu-to-PCI bridge being primarily a PCI device.  Not 
necessarily a problem per-se, but certainly seems a strange outcome.
 
> >>> It's somewhat unlear what the purpose of composition is.  Using
> >>> composition for piix4::piiix and piix3::i8042 seems wrong.  In fact
> >>> piix3 shouldn't have any knowledge of i8042 at all, it's just annother
> >>> random ISA device.
> >> 
> >> i8042 is not a random ISA device.  It lives in the piix3 and the piix3
> >> has intimate knowledge of it.  When model a20 line propagation, this is
> >> actually an important detail.
> > 
> > Huh? I see absoutely no relationship between piix3 and i8042.
> > It happens that on the PC machine they are etched into the same piece of
> > silicon and one of the i8042 GPIO pins it connected to the A20 gate
> > input, but the devices have no actual knowledge of each other.
> 
> Composition == "etching to the same piece of silicon".  Nothing more,
> nothing less.

That's a really crappy definition.  Most ARM systems are comprised of 
approximately one piece of silicon.  There may be dozens of variants of a 
particular chip, with the same device models stamped into the silicon slightly 
different ways.

IMO it would be much better to split on logical device boundaries.  Especially 
when the functionality provided (pci to ISA bridge) works perfectly well 
without the child device.

> A device has no knowledge of the fact that it is a child of another device.
>
> > If you're wanting to provide a convenient way of instantiating common
> > clumps of devices then I think that should be separate.  Likewise
> > defining convenient machine specific aliases for users.
> 
> There is a separate container device that lets you create arbitrary
> collections of devices, but in many cases, we can achieve better code
> reuse by using composition.
>
> Consider the serial device.  In QOM, I've got it modelled as:
> 
> MMSerial has-a UART
> ISASerial has-a UART
> 
> And there are lots of cases where a design is compatible with a UART16650A
> but adds additional logic/features.  In those cases, we would do:
> 
> MCFSerial is-a UART

Are you using UART as shorthand for UART16550A? Or is UART a base object that 
implements pure virtual methods for register access and properties for 
CharDevice and IRQ output. UART16550 inherits from and provides the 
implementation? So a UART8250 or UART6551 could act as drop-in replacements 
(replacing has-a UART with links-to-a UART).

> Now you could certainly remove the has-a logic and make it so something had
> to instantiate a UART separately from the ISASerial device and connect
> things up but that's overly complicated IMHO.

Why not ISASerial is-a UART? I guess because both are stateful, so not allowed 
by our inheritance model?
We could presumably do:
  ISASerial is-a UART has-a ISADevice
It seems like a map-isa-io-to-registers device has at least as may reuse 
opportunities as register-based-uart.

How is MCFSerial different?  Are we expecting MCFSerial to poke around in 
private UART16550 rather than just feeding it cooked data?  If so isn't it 
mode likely to end up as:

UARTMCF is-a UART16550 // with knobs on.
MCFSerial is-a ColdfireBusDevice has-a UART

> > So the link is to an Interface, not a device?
> 
> Devices are Objects
> 
> All Objects have Types.  An interface is just another Type.  Types can
> inherit from other types.

Ah, I think I see.  The trick is that this effectively gives multiple 
inheritance as long as no more than one base type has state (i.e. data 
members).
 
> All devices inherit from the DeviceState type.
> 
> A link has a Type associated with it.  The Type can be an interface, or it
> can be a stateful base class, or it can be a Type that isn't derived at
> all from Device (like a CharDriverState).

Ok. I suspect we may have slightly different ideas what constitutes a 
"Device", but I'll leave that for now.
 
> >  To support multiple instances
> > of the same interface we use a closure-like proxy object?
> 
> If you needed to, but I think most of the time, that's not necessary.

I don't see how this can work without a closure object.  We need a central 
device that is capable of recieving signals from many client devices.  Those 
client devices don't know where they are, they just shout down a point-point 
link. I'd say this is a fairly common topology.

If the central device implements that point-point interface directly then it 
has no idea which device is talking to it.  We need to create child objects 
with a port ID property and implementing the p-p interface, then bind each 
client device to one of these child objects.  The child objects can't do 
anything useful on their own, so need to proxy the signal to an interface on 
the main object, adding in their port id.

Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]