All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Stefan Hajnoczi" <stefanha@gmail.com>,
	"Andreas Färber" <afaerber@suse.de>,
	qemu-devel@nongnu.org, "Evgeny Voevodin" <e.voevodin@samsung.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] Can we improve virtio data structures with QOM?
Date: Fri, 01 Jun 2012 17:32:24 +0800	[thread overview]
Message-ID: <4FC88C28.8070100@codemonkey.ws> (raw)
In-Reply-To: <m3fwaf9yec.fsf@blackfin.pond.sub.org>

On 06/01/2012 05:25 PM, Markus Armbruster wrote:
> Anthony Liguori<anthony@codemonkey.ws>  writes:
>
>> On 06/01/2012 12:48 AM, Markus Armbruster wrote:
>>> Anthony Liguori<anthony@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?

Then the user did something silly.

If you're really asking, should we expect a user to use a command line like 
this?  Absolutely not!

A user should use something like -drive file=foo.img,if=virtio

Heck, I still think we should do -vda foo.img.

> 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.

Most likely they will.  But I don't think users should be setting any links in 
the first place.

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

Actually, in qdev it's called parent_bus.

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

I actually just did a tutorial session out here walking through how to write 
device emulation from scratch.  I would thinking of making a QOM Style Guide 
based on that.  I'm pretty short on free time for the next week but I'll try to 
queue it up.  If anyone wants to take a first pass, I'd happily review it and 
contribute.

>> BTW, I make no mention of BusState here.  That's intentional.  There's
>> no need to involve buses IMHO.
>
> I never liked qbus anyway.

qbus never liked any of us too FWIW.  It was a real jerk that way.

Regards,

Anthony Liguori

  reply	other threads:[~2012-06-01  9:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m3txyx514d.fsf@blackfin.pond.sub.org>
     [not found] ` <CAJSP0QVSaRvr-13o=o7pZ2UL999C+yim=fFE_iBoLA--BC9_-g@mail.gmail.com>
     [not found]   ` <m3pq9lfxb0.fsf@blackfin.pond.sub.org>
     [not found]     ` <4FC6A71A.90303@codemonkey.ws>
     [not found]       ` <m38vg8i9em.fsf@blackfin.pond.sub.org>
2012-06-01  8:12         ` [Qemu-devel] Can we improve virtio data structures with QOM? Anthony Liguori
2012-06-01  9:25           ` Markus Armbruster
2012-06-01  9:32             ` Anthony Liguori [this message]
2012-06-01 11:43               ` Markus Armbruster
2012-06-02  9:31                 ` Anthony Liguori
2012-06-04 16:40                   ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FC88C28.8070100@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=afaerber@suse.de \
    --cc=armbru@redhat.com \
    --cc=e.voevodin@samsung.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.