From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sakgs-0001yM-NS for qemu-devel@nongnu.org; Sat, 02 Jun 2012 05:32:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sakgq-0007zp-KN for qemu-devel@nongnu.org; Sat, 02 Jun 2012 05:32:10 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:55000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sakgq-0007zY-B1 for qemu-devel@nongnu.org; Sat, 02 Jun 2012 05:32:08 -0400 Received: by dadv2 with SMTP id v2so4136036dad.4 for ; Sat, 02 Jun 2012 02:32:05 -0700 (PDT) Message-ID: <4FC9DD8A.4020607@codemonkey.ws> Date: Sat, 02 Jun 2012 17:31:54 +0800 From: Anthony Liguori MIME-Version: 1.0 References: <4FC6A71A.90303@codemonkey.ws> <4FC87960.2090206@codemonkey.ws> <4FC88C28.8070100@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Can we improve virtio data structures with QOM? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Stefan Hajnoczi , Paolo Bonzini , =?ISO-8859-1?Q?Andreas_F=E4rb?= =?ISO-8859-1?Q?er?= , Evgeny Voevodin , qemu-devel@nongnu.org On 06/01/2012 07:43 PM, Markus Armbruster wrote: > Anthony Liguori 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. >