From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIDPd-0002cC-Pc for qemu-devel@nongnu.org; Tue, 25 Feb 2014 03:30:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIDPW-0005o1-Fp for qemu-devel@nongnu.org; Tue, 25 Feb 2014 03:30:49 -0500 Received: from cantor2.suse.de ([195.135.220.15]:36400 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIDPW-0005ns-9I for qemu-devel@nongnu.org; Tue, 25 Feb 2014 03:30:42 -0500 Message-ID: <530C54AE.8000608@suse.de> Date: Tue, 25 Feb 2014 09:30:38 +0100 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <20140221091629.GE11907@stefanha-thinkpad.redhat.com> <530764B0.40500@redhat.com> <5307BE7A.5050007@redhat.com> <87ha7o6hhj.fsf@blackfin.pond.sub.org> <530B6E85.30709@redhat.com> <87y50zsinq.fsf@blackfin.pond.sub.org> In-Reply-To: <87y50zsinq.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] QOM vs QAPI for QMP APIs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Eric Blake Cc: Anthony Liguori , qemu-devel@nongnu.org, Michael Roth , Luiz Capitulino , Stefan Hajnoczi , Paolo Bonzini , Anthony Liguori Am 25.02.2014 09:25, schrieb Markus Armbruster: > Eric Blake writes: >=20 >> On 02/24/2014 01:29 AM, Markus Armbruster wrote: >> >>>> >>>> The other burden is documenting what QOM paths to be queried, and >>>> knowing where to find that documentation. That is, it's another lay= er >>>> of complexity, but it's also a more powerful expression. >>>> >>>> I'm comparing this situation somewhat to libvirt's 'virsh >>>> qemu-monitor-command' vs. other libvirt commands. qemu-monitor-comm= and >>>> is a more powerful interface (via libvirt, you can issue ANY qmp >>>> command), and is therefore great for development for testing somethi= ng >>>> that libvirt has not yet supported; but not so nice to the end user >>>> (it's use is explicitly unsupported). What happens is that as peopl= e >>>> say "I had to use qemu-monitor-command to do task A", it is a hint t= o >>>> libvirt development to say "oh, we need to add an API to make task A >>>> easier to do". >>>> >>>> Thus, having qom-find-objects-by-class is a good idea, even if it is >>>> more awkward to use than a dedicated qmp command. But meanwhile, we >>>> should watch what common patterns it gets used for, and add dedicate= d >>>> QMP commands for those patterns. It's much faster to get a chunk of >>>> information in one QMP call already formatted into desired structs t= han >>>> it is to make a series of QMP calls to learn about the lower-level q= om >>>> model one piece at a time. >>> >>> You didn't spell out the ABI promises here. Do you argue for providi= ng >>> QOM interfaces as unstable low-level interfaces? >> >> Haven't we already done that in the past? For example, object-add >> currently takes an unspecified dictionary of options, where you would >> have to consult QOM documentation to learn what makes sense to send. >=20 > My question isn't about where the command details are documented, or > even whether they are documented. It's about ABI promises, or lack > thereof. The general promise for QMP is we treat it as stable ABI. If > we add QMP commands to examine and manipulate QOM, doesn't that move al= l > of QOM under the QMP ABI promise, unless we explicitly excempt it? Anthony has clearly stated and I have been repeating that QOM follows strict ABI stability rules for its properties, and that therefore applies to what some of you still call "qdev" as well. Therefore my nagging to get underscores vs. dashes right for new properties and questioning attempted type changes without changing the property name. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg