qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] KVM call agenda for tuesday 31


From: Avi Kivity
Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31
Date: Tue, 31 Jan 2012 16:44:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

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ä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.

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.

-- 
error compiling committee.c: too many arguments to function




reply via email to

[Prev in Thread] Current Thread [Next in Thread]