Of course we then hit the usual problem with QOM that we can only link
to objects, and it's impossible to expose multiple interfaces of the
same type.
I'm pretty sure Anthony claimed this was entirely possible --
presumably that's how Pins are going to work.
Really? Every time I've talked to him I've got the opposite impression.
Part of the response has been that interrupt pins are the only case
where this actually occurs, so It's not worth fixing properly.
I think it depends on your definition of "properly".
There's really only three concepts in QOM that matter for this discussion:
1) objects 2) children and 3) links.
There is absolutely no difference between a Pin object and a SerialState
object. They both are first-class objects are far as QOM and concerned.
Both can have links to other objects.
The most common way for other objects to create objects is via children. A
device could have a bunch of Pin child objects with that being the sole
communication mechanism with the outside world.
And those pin objects would presumably communicate back to the device via some
as-yet unimplemented PinMultiplex interface link? Or are you expecting the
Pin objects to have an API call that allows the device to register an
arbitrary QEMUBH (or equivalent)?
A device could also have a 'PCISocket' child object (which inherits from
PCIDevice) in order to expose a PCI interface to the world.
For most bus-based devices, I think the above is poor design. But that's
my opinion from a modeling PoV, QOM doesn't have an opinion from an
infrastructure PoV.
So what is a good design? Are you hoping most of your interfaces are
stateless, so can be implemented directly on the device object?