From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31
Date: Tue, 31 Jan 2012 08:17:22 -0600
Message-ID: <4F27F7F2.1050606@codemonkey.ws>
References: <87ehuhrpel.fsf@elfo.elfo> <4F272A92.2010609@suse.de>	<4F27F3DB.2040400@codemonkey.ws> <4F27F61B.6040806@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
	format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Peter Maydell <peter.maydell@linaro.org>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	=?UTF-8?B?6Zmz6Z+L5Lu7?= <chenwj@iis.sinica.edu.tw>,
	quintela@redhat.com, Stefan Weil <sw@weilnetz.de>,
	Developers qemu-devel <qemu-devel@nongnu.org>,
	=?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>,
	Alex Bradbury <asb@asbradbury.org>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-pz0-f46.google.com ([209.85.210.46]:33419 "EHLO
	mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753320Ab2AaOR2 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 31 Jan 2012 09:17:28 -0500
Received: by dadp15 with SMTP id p15so241951dad.19
        for <kvm@vger.kernel.org>; Tue, 31 Jan 2012 06:17:27 -0800 (PST)
In-Reply-To: <4F27F61B.6040806@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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 sta=
bilizes
>
> the first two seem very similar, except for the "not".

I guess I really mean QMP compatible.  The expectation is that well wri=
tten=20
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 ch=
ange.=20
Backwards compatibility would mean that once qom-list is introduced, it=
 never=20
goes away.

In terms of QOM types, we won't guarantee that a Type will stick around=
 forever,=20
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=20
series, I'm sure we're going to go through a few significant refactorin=
gs that=20
change types significantly.

Regards,

Anthony Liguori

>
>