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

[Paul Brook]

> >> 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.
> 
> What I'm really after is to have a way to do "-device piix3" and get all of
> the devices that would normally live on the piix3.  If it's desirable to
> split out piix3 into piix3-isa-bridge which is part of piix3 and can be
> used independently such that piix3 is just a thin container of
> piix3-isa-bridge and everything behind it, that's fine by me.

Yes, that's what I was imagining.

> We should do whatever makes sense for the machine/target.  For pc, I've
> seen absolutely zero interest in someone creating a pc machine without an
> i8042 or an RTC.

For a PC that actually is an interesting config - chipset manufacturers have 
been threatening to do it for years, and I believe a good fraction is already 
emulated via SMM.

For the PIIX3 specifically I'm not sure how many different variants there are 
in terms of number of peripherals, USB ports, etc.  I'm pretty sure there are 
several models, but I don't know whether the defferences are purely 
electrical/packaging.

> >> 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?
> 
> That's actually how I implemented MMSerial just to show that it's possible.
> 
> I prefer has-a because if you had a real life ISA card with a UART16550A on
> it, the ISA card would have an identifiable UART16650A on it.  I think
> it's unlikely that you would have a single chip with an ISA-compatible
> pin-out that happened to be compatible with a UART16550A.

Hmm, maybe. OTOH it's exactly the sort of corner that might beworth cutting if 
you're knocking out ISA serial card clones by the million :-)

> > I guess because both are stateful, so not allowed
> > by our inheritance model?
> 
> Right, but ISADevice could very easily become an Interface as it has no
> state today.

Maybe. I'm not entirely convinced that is viable solution going forward.

Do we have a user interface issue here?  If at some later point we discover 
that both bus and device need some state then we'll need to split the device.  
I didn't follow the device naming thread in detail, so maybe this has already 
been covered.

> > 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:
> Yes, it could go either way really but I would expect that MCFSerial would
> override the ioport_read() and ioport_write functions and implement custom
> functionality that way.

The fact that serial.c (which really should be called 16550.c) contains ISA 
specific IO callback routines feels like ISASerial isn't doing its job 
proberly to start with :-)
 
> > 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.
> 
> If you aren't using inheritance, yes, you need to pass closures to the
> child objects.  I dislike that kind of proxy modeling.

How would you solve this using inheritance?

I can see how it works when the device knows its address, but it seems kinda 
lame to tell a device "You have a dedicated communication channel.  But I'm 
lazy and will smush them all together.  Please add this additional token to 
every signal you send".
 
> I wonder how common is it though to have this kind of scenario where the
> bus protocol doesn't have any kind of identifier that identifies the
> target bus.  I presume in most cases you're thinking about, there's a
> single transport that can multiplex communications, no?

Not really.  Either individual transports, or multiplexing that is not visible 
to client devices.

After further thought IRQs are the only concrete example I can come up with.  
Others tend to have one [logical] host device per bus (various forms of 
serial), be host driven (USB, mostly), or deliberately make the link-level 
details software transparent (PCIe).

I suspect SMBus (sun4m) may be a candidate, though I could be wrong.

Paul