From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsExQ-0005aW-BX for qemu-devel@nongnu.org; Tue, 31 Jan 2012 09:45:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsExJ-0003xf-Ki for qemu-devel@nongnu.org; Tue, 31 Jan 2012 09:45:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:61757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsExJ-0003x5-E2 for qemu-devel@nongnu.org; Tue, 31 Jan 2012 09:45:09 -0500 Message-ID: <4F27FE62.5020701@redhat.com> Date: Tue, 31 Jan 2012 16:44:50 +0200 From: Avi Kivity MIME-Version: 1.0 References: <87ehuhrpel.fsf@elfo.elfo> <4F272A92.2010609@suse.de> <4F27F3DB.2040400@codemonkey.ws> <4F27F61B.6040806@redhat.com> <4F27F7F2.1050606@codemonkey.ws> In-Reply-To: <4F27F7F2.1050606@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori 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 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. >>> >>> 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 stab= ilizes >> >> 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, and 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