From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIEao-0001aB-L9 for qemu-devel@nongnu.org; Tue, 25 Feb 2014 04:46:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIEai-0006g2-L6 for qemu-devel@nongnu.org; Tue, 25 Feb 2014 04:46:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:27287) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIEai-0006fr-D9 for qemu-devel@nongnu.org; Tue, 25 Feb 2014 04:46:20 -0500 Date: Tue, 25 Feb 2014 10:46:15 +0100 From: Kevin Wolf Message-ID: <20140225094615.GA3339@dhcp-200-207.str.redhat.com> References: <20140221091629.GE11907@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] QOM vs QAPI for QMP APIs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Stefan Hajnoczi , qemu-devel , Michael Roth , Luiz Capitulino , Anthony Liguori , Paolo Bonzini , Andreas Faerber Am 21.02.2014 um 15:32 hat Stefan Hajnoczi geschrieben: > On Fri, Feb 21, 2014 at 10:16 AM, Stefan Hajnoczi wrote: > > Maybe I just need some convincing but it seems that QAPI is the simplest > > and cleanest way to define external APIs. > > > > Disagree? Tell me why :). > > I'm replying to myself because we had an interesting discussion on > IRC. Thanks Paolo, Markus, and Peter! > > I'm biased, but here are the points collected from the discussion: > > Why QOM *should* be QEMU's external API: > * QOM eliminates hand-written QMP API code. We get query-foo APIs > for free using qom-list, qom-get, qom-set, and friends I don't think this is valid point. We already have a QAPI code generator. There's no reason why it couldn't automatically map things to QOM for certain commands. This means that you would internally use QOM in order to get rid of hand-written code, but it would be an implementation detail and the external API would still be as high-level as it is today. > Why QOM should *not* be QEMU's external API: > * Internal objects will diverge from the external QOM objects over > time, we'll have to maintain a backwards compatible QOM object layer > on top of QEMU's internal objects - that defeats the whole point of > getting APIs for free from QOM This is a very important point. We already managed to mess up existing QMP commands so that we're jumping through hoops to provide an old interface, which doesn't really match the design we want to have. Sometimes it prevents us from making changes. With QOM, we potentially expose everything, every little detail of our internal implementation. If we don't say that there is no (or at least very weak) compatibility promise, then we're forever stuck with whatever broken design we first came up with. If QOM comes with stability requirements, I'll veto any conversion patch of any part of the block layer to QOM. > * We lose the easy-to-review qapi-schema.json. Would need new > documentation and review tools for QOM model changes. > * query-foo APIs are simple to implement, not a huge win to get them via QOM > * QAPI is mature and well-understood, QMP is incomplete > * qom-list, qom-get, qom-set are too low-level, need more powerful > APIs to save clients from elaborate back-and-forth conversations Right, QOM is simple in the way that programming in assembly is simple. The building blocks are really simple and easy to explain, but building something higher level from it is hard and easy to get wrong. Try expressing a 'transaction' QMP command with multiple newly created snapshots and a backup job in QOM... (without creating a transaction object that contains the current QAPI arguments as properties, because that wouldn't really be using QOM but tunneling QMP through QOM) External QOM interfaces have their place, especially for debugging or trying out things before there is a proper API, but it's not as the primary external interface. Kevin