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

[Anthony Liguori <anthony@codemonkey.ws>]

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