From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsEWd-0003ol-Lp for qemu-devel@nongnu.org; Tue, 31 Jan 2012 09:17:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsEWW-000662-LZ for qemu-devel@nongnu.org; Tue, 31 Jan 2012 09:17:35 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:62504) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsEWW-00065l-FR for qemu-devel@nongnu.org; Tue, 31 Jan 2012 09:17:28 -0500 Received: by dadp14 with SMTP id p14so322972dad.4 for ; Tue, 31 Jan 2012 06:17:27 -0800 (PST) Message-ID: <4F27F7F2.1050606@codemonkey.ws> Date: Tue, 31 Jan 2012 08:17:22 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <87ehuhrpel.fsf@elfo.elfo> <4F272A92.2010609@suse.de> <4F27F3DB.2040400@codemonkey.ws> <4F27F61B.6040806@redhat.com> In-Reply-To: <4F27F61B.6040806@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity 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 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ärber 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 > – We can re-examine this as the device model matures and stabilizes > > 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. Regards, Anthony Liguori > >