[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] Can we improve virtio data structures with QOM?
Date: Sat, 02 Jun 2012 17:31:54 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 06/01/2012 07:43 PM, Markus Armbruster wrote:
Anthony Liguori<address@hidden>  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

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 


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.


reply via email to

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