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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
