> The full set of devices names and properties used in this example are
> below:
>
> Type: I440FX
> Is-a: Device
> Implements: PciBus
> Name: i440fx
> Properties:
> piix3: Composition<PIIX3>
> slot[1.0]: Backlink<PciDevice>
>
> Type: PIIX3
> Isa-a: PciDevice
> Implements: IsaBus
> Name: i440fx::piix3
> Properties:
> i8042: Composition<I8042>
> bus: Backlink<PciDevice> (inherited from PciDevice)
>
> Type: I8042
> Isa-a: Device
> Implements: Ps2Controller
> Name: i440fx::piix3::i8042
> Properties:
> aux: Backlink<Ps2Mouse>
I haven't looks at the patches in detail, but your description looks fairly
dubious in its current form.
Is the type of piix3::bus a typo? I think this should be Backlink<PciBus>.
What is the difference between "Is-a" and "Implements"? 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.
I'm not so sure we should have Is-a at all. Isn't the point of replacing the
bus/device hierachy with a set of links that devices don't follow a simple
tree structure? It's fairly common for the tree branches to merge back
together when a single device communicates via multiple busses.
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.
Speaking of which, presumably i8042 should be an IsaDevice, which inherits
(amongst other things) a bus: Backlink<IsaBus> property.
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>
Type: MagicInterruptPin
Implements: IRQ
Properties:
pin_number: int
controller: BackLink<MagicInterruptInterface>
It seems like rather than having a device implement a set of interfaces, it
might be better to have these be properties. Call them a Target<>. The above
then becomes something like:
Type: MagicInterruptController
Is-a: SystemBusDevice
Properties:
in_pin0: Target<IRQ>
in_pin1: Target<IRQ>
out_pin: Link<IRQ>
Where the Target<> properties are objects/methods provided by the device, and
the Link<> properties are pointed to them as the machine is constructed.
Paul
