Anthony Liguori <anth...@codemonkey.ws> writes: > On 06/01/2012 12:48 AM, Markus Armbruster wrote: >> Anthony Liguori<anth...@codemonkey.ws> writes: >> >> [On how to model virtio devices in QOM:] >>> Basically, it should look like: >>> >>> VirtioPCIDevice is-a PCIDevice >>> >>> VirtioPCIDevice has-a link<VirtioDevice> >> >> Could you explain why this is link<> and not child<>? > > So you can do: > > qemu -device virtio-pci,id=foo,vdev=bar -device virtio-blk,id=bar,bus=foo
This lets folks specify both directions of the virtio-pci <-> virtio-blk connection independently. What if $dev->bus->vdev != $dev, i.e. the backlink doesn't point back? Easiest way to avoid that is to deny access to the backlink, and set it automatically instead. Wouldn't be surprised if such bi-directional links turned out to be a pretty common pattern. In qdev, we've always called the property naming the parent "bus", because it's always been a qbus. Doesn't make sense here: the property refers to a device, not a bus. Should we call it something else? > The alternative would be: > > qemu -device virtio-pci,id=foo,child_type=virtio-blk > > But that feels ugly to me. If you want to have a variable type of > device, a link is the right tool. Okay, that's a general rule (I was hoping you'd state one). Do we have a place for such rules, or do we expect people to learn them by osmosis? > BTW, I make no mention of BusState here. That's intentional. There's > no need to involve buses IMHO. I never liked qbus anyway.
