> >>> 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? Paul