From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31 Date: Tue, 31 Jan 2012 16:44:50 +0200 Message-ID: <4F27FE62.5020701@redhat.com> References: <87ehuhrpel.fsf@elfo.elfo> <4F272A92.2010609@suse.de> <4F27F3DB.2040400@codemonkey.ws> <4F27F61B.6040806@redhat.com> <4F27F7F2.1050606@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Peter Maydell , KVM devel mailing list , =?UTF-8?B?6Zmz6Z+L5Lu7?= , quintela@redhat.com, Stefan Weil , Developers qemu-devel , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Alex Bradbury To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37364 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753061Ab2AaOpL (ORCPT ); Tue, 31 Jan 2012 09:45:11 -0500 In-Reply-To: <4F27F7F2.1050606@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 01/31/2012 04:17 PM, Anthony Liguori wrote: > On 01/31/2012 08:09 AM, Avi Kivity wrote: >> On 01/31/2012 03:59 PM, Anthony Liguori wrote: >>> On 01/30/2012 05:41 PM, Andreas F=C3=A4rber wrote: >>>> Am 30.01.2012 19:55, schrieb Juan Quintela: >>>>> Please send in any agenda items you are interested in covering. >>>> >>>> QOM roadmap update: >>>> * Series 3/4 is on the list. >>>> -> Please officially designate a merge date (Friday?). >>>> -> To make review sensible, I ask for a hard device freeze until >>>> merged. >>>> I.e., no new devices and no conflicting changes to DeviceInfo= =2E >>> >>> I put together a few slides to help this discussion: >>> >>> http://www.codemonkey.ws/files/qom-overview.pdf >>> >> >> That was helpful, thanks. >> >> Can you clarify >> >> - Types and their properties will be ABI compatible >> - Types and properties will not be backwards compatible >> =E2=80=93 We can re-examine this as the device model matures and st= abilizes >> >> the first two seem very similar, except for the "not". > > I guess I really mean QMP compatible. The expectation is that well > written management code does: > > if (check_for_command("qom-list")) { > run_command("qom-list", "/"); > } > > ABI compatible means that if qom-list is there, it's semantics never > change. Backwards compatibility would mean that once qom-list is > introduced, it never goes away. > > In terms of QOM types, we won't guarantee that a Type will stick > around forever, but we will guarantee if it's there, it'll behave in = a > certain way. > > When the device model stabilizes over time, we can revisit this, but > in the 1.x series, I'm sure we're going to go through a few > significant refactorings that change types significantly. Ok. We have to communicate this very carefully. If a management tool uses something that is ABI compatible, but not backwards compatible, an= d lacks a known alternative at the time of writing the management tool, then the "ABI-compatible-but-not-backwards-compatible" property becomes "not backwards compatible" to the management tool's users. --=20 error compiling committee.c: too many arguments to function