qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Can we improve virtio data structures with QOM?


From: Markus Armbruster
Subject: Re: [Qemu-devel] Can we improve virtio data structures with QOM?
Date: Fri, 01 Jun 2012 11:25:47 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 06/01/2012 12:48 AM, Markus Armbruster wrote:
>> Anthony Liguori<address@hidden>  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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]