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.