> It's multiple inheritance but interfaces (implements) cannot carry state > which avoids an inheritance diamond problem.
> > It sounds like some > > form of multiple inheritance, but it's unclear to me which should be the > > primary type. For PCI host bridges like the i440fx we currently have to > > split them into two, one fot the host bus and the other for the PCI bus. > > It feels like if we design the model properly this should no longer be > > necessary. > > Yes, that's exactly what this solves. I think we could probably make > i440fx is-a PCIDevice that implements a PciBus. It's the same thing we > would do with a PCI Bridge. Hmm, so how does that work given all of SysbusDevice, PCIDevice and PciBus have state? Making PciBus a separate (composition/shild) object is IMHO not a bad thing anyway - I dislike saying that the device and the bus are the same thing. 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. Similar examples occur when we have an audio codec with both an i2c command interface and an SSI data port. > > I'm not so sure we should have Is-a at all. > > A point that has been repeatedly brought up is that you can avoid primary > inheritance and just rely on composition using composed interfaces as your > communication vehicle. > > I think in some cases, that will make sense, and the object model allows > that. I'm not sure choice is a good thing here! One of the mistakes I made with qdev was to insufficiently document how the device model was supposed to fit together. This resulted in several bastardised qdev "conversions" involving gratuitous layering violations. The end result was that these devices are effectively useless as qdev objects, and propagate all the problems that qdev was designed to fix. It would be good to at least have guidelines on how and why the different approaches should be used. Especially for those of us who maybe aren't convesant with the more theoretical/academic principles/terminology behind OO design. If it's only a good idea in some cases then you can pretty much guarantee a large number of developers will try and use it in the cases where it isn't, and vice-versa ;-) > > 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. 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. > > What happens when my device has multiple parts that need to be referred > > to by other devices? An interrupt controller is the most obvious > > example, but similar issues occur for any device that has multiple > > connections of the same type. Am I expected to create a whole bunch of > > dummy devices and a private interface to bounce everything back to the > > main device, somethig like: > > > > Type: MagicInterruptController > > > > Is-a: SystemBusDevice > > Implements: MagicInterruptInterface > > > > Properties: > > in_pin0: Composition<MagicInterruptPin, pin_number=0, > > controller=this> > > in_pin1: Composition<MagicInterruptPin, pin_number=1, > > controller=this> > > out_pin: link<IRQ> > > No, there would be a single 'Pin' class that would be used for irqs. There > is no need to subclass it. > > > > > Type: MagicInterruptController > > > > Is-a: SystemBusDevice > > > > Properties: > > in_pin0: Target<IRQ> > > in_pin1: Target<IRQ> > > out_pin: Link<IRQ> > > So this is more like how it works today except s/Link/child/ and > s/Target/link/g. Isn't that the other way around? The input pin owns the IRQ object, and the output pin is the board/machine/user configured reference to that object. So the link is to an Interface, not a device? To support multiple instances of the same interface we use a closure-like proxy object? I guess it we assume the number of interface classes is relatively small that should work. Paul
