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

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

[Anthony Liguori]

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

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.

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

Regards,

Anthony Liguori

>
>> VirtioDevice is-a DeviceState
>>
>> VirtioBlk is-a VirtioDevice
>> VirtioNet is-a VirtioDevice
>> ...
>>
>> VirtioPCIBlk is-a VirtioPCIDevice
>> VirtioPCIBlk has-a child<VirtioBlk>
>>
>> This gives us backwards compat while also providing a cleaner
>> model. VirtioPCIBlk et al would be deprecated eventually (but not any
>> time soon).

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

[Markus Armbruster]

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?

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.

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

[Anthony Liguori]

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

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

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> 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

No, a user should use what solves his problem nicely.

Most of the time, the problem is simple.  I quite agree we should
provide simple ways to solve the known simple problems.

Occasionally, you run into a non-simple problem, and then you'll really
appreciate a discoverable bridge from the simple way to the general way.
You'll also appreciate when the general way still satisfies basic
usability criteria.

A mandatory parameter that must have the one right value, or else things
break, doesn't satisfy.

"Experts/tools only" is no excuse for shoddy interfaces.

-drive isn't such a good example for "simple"; it's a bloody mess, in my
opinion.

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

Real tools aren't built around ideas on what users shouldn't be doing
with them.

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

Still got that bogus "bus" in there :)

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

That should be really useful.

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

Heh.

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

[Anthony Liguori]

On 06/01/2012 07:43 PM, Markus Armbruster wrote:
> Anthony Liguori<anthony@codemonkey.ws>  writes:

>
> No, a user should use what solves his problem nicely.
>
> Most of the time, the problem is simple.  I quite agree we should
> provide simple ways to solve the known simple problems.
>
> Occasionally, you run into a non-simple problem, and then you'll really
> appreciate a discoverable bridge from the simple way to the general way.
> You'll also appreciate when the general way still satisfies basic
> usability criteria.
>
> A mandatory parameter that must have the one right value, or else things
> break, doesn't satisfy.
>
> "Experts/tools only" is no excuse for shoddy interfaces.

Links are unidirectional.  A pair of links provides a bidirectional interface. 
Today we don't have a mechanism to establish a pair of links.  It's unclear to 
me what such an interface ought to look like.

I'm not fundamentally opposed to such an interface, but this would be syntactic 
sugar IMHO.

And I strongly disagree with your statements above.  It's lazy interface design 
to have a "low level interface" and tell users that if they can't do what they 
want with our high level interface, they must drill down to the low level.

> -drive isn't such a good example for "simple"; it's a bloody mess, in my
> opinion.
>
>> Heck, I still think we should do -vda foo.img.

See above.

>> Most likely they will.  But I don't think users should be setting any
>> links in the first place.
>
> Real tools aren't built around ideas on what users shouldn't be doing
> with them.

I disagree.  That's what UX is all about.  But really, let's step back before we 
run off a cliff debating abstract notions.

QOM's is an API.  It's not meant for casual users to do anything with.  It 
should be a *usable* API and APIs that are hard to misuse are definitely a Good 
Thing.

I tried very hard to add features to QOM to make it difficult to miss set 
properties which is why everything is aggressively typed.  I'm violently in 
favor of making it a safer interface.

But let's not conflate good API design with UX.  They are very different things. 
  And yes, this is why QOM only really supports QMP today as an interface.

>>> 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.
>
> Still got that bogus "bus" in there :)

Long term, I'd like to refactor away buses.  It should be easy for the most part.

Regards,

Anthony Liguori

>
>>>> 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.
>
> That should be really useful.
>
>>                              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.
>
> Heh.
>

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

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> On 06/01/2012 07:43 PM, Markus Armbruster wrote:
>> Anthony Liguori<anthony@codemonkey.ws>  writes:
>
>>
>> No, a user should use what solves his problem nicely.
>>
>> Most of the time, the problem is simple.  I quite agree we should
>> provide simple ways to solve the known simple problems.
>>
>> Occasionally, you run into a non-simple problem, and then you'll really
>> appreciate a discoverable bridge from the simple way to the general way.
>> You'll also appreciate when the general way still satisfies basic
>> usability criteria.
>>
>> A mandatory parameter that must have the one right value, or else things
>> break, doesn't satisfy.
>>
>> "Experts/tools only" is no excuse for shoddy interfaces.
>
> Links are unidirectional.  A pair of links provides a bidirectional
> interface. Today we don't have a mechanism to establish a pair of
> links.  It's unclear to me what such an interface ought to look like.
>
> I'm not fundamentally opposed to such an interface, but this would be
> syntactic sugar IMHO.
>
> And I strongly disagree with your statements above.  It's lazy
> interface design to have a "low level interface" and tell users that
> if they can't do what they want with our high level interface, they
> must drill down to the low level.

Sure, except it's not what I proposed.

There needs to be a simple way to solve simple problems.

There needs to be a general way, so that even non-simple problems can be
solved.

There should be a discoverable bridge from the simple way to the general
way.  Adding optional arguments to the simple way is such a bridge.
Sometimes your simple way can't do that, and then you need to think
about alternatives.

>> -drive isn't such a good example for "simple"; it's a bloody mess, in my
>> opinion.
>>
>>> Heck, I still think we should do -vda foo.img.
>
> See above.

I don't mind -vda as additional shorthand notation.  Would be bad if it
was the only simple way, though.

>>> Most likely they will.  But I don't think users should be setting any
>>> links in the first place.
>>
>> Real tools aren't built around ideas on what users shouldn't be doing
>> with them.
>
> I disagree.  That's what UX is all about.  But really, let's step back
> before we run off a cliff debating abstract notions.
>
> QOM's is an API.  It's not meant for casual users to do anything with.
> It should be a *usable* API and APIs that are hard to misuse are
> definitely a Good Thing.
>
> I tried very hard to add features to QOM to make it difficult to miss
> set properties which is why everything is aggressively typed.  I'm
> violently in favor of making it a safer interface.

If a pair of links must point back to each other for things to work,
then we have a safety issue and a design issue:

Safety: do not permit settings that cannot work (unless detecting the
misuse is impractical).

Design: do not make me specify mandatory parameters that can take only
one value (unless the redundancy serves a worthwhile purpose).

Both apply to API just as much as to UX.

> But let's not conflate good API design with UX.  They are very
> different things. And yes, this is why QOM only really supports QMP
> today as an interface.
[...]