Re: [Qemu-devel] [PATCH 00/18] qom: dynamic properties and composition tree

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/01/2011 08:48 AM, Avi Kivity wrote:
> On 12/01/2011 04:42 PM, Anthony Liguori wrote:
>>
>>>
>>> We need good tools to allow easy review of the ABI bits hiding in
>>> patches, and to maintain ABI compatibility.  Something like
>>> qemu-print-abi that dumps all properties for all devices.  Patches could
>>> show the ABI changes by including a diff of the output of this program
>>> from before and after a change, and we could add similar tests for
>>> backwards compatibility.
>>
>> I'm not sure that we want this interface to be backwards compatible.
>> I actually think we should provide a higher level interface that's
>> explicitly there for compatibility.  Probably in the form of a C
>> library that can be documented and reasoned with better.
>>
>
> Does this force anyone who wants a stable ABI to use this library?
>
> I don't have a good picture of this library.  If FooState has a bar
> propery, do you generate qemu_foo_get_bar() and qemu_foo_set_bar()
> accessors?

This is all extremely low level stuff.  My view is that if you are a user that 
cares about backwards compatibility, you probably don't want all of this low 
level stuff in the first place.

I think we need to provide two classes of interfaces.  A low-level interface 
that only something like libvirt would consume that is not 100% backwards 
compatible and a higher-level interface that less sophisticated tools would consume.

If we provide a not 100% backwards compatible interface, then we would also need 
to provide a good introspection/capabilities mechanism so that something like 
libvirt could find out whether a feature was available or whether a device has 
changed significantly.

To be very clear, I think "-drive if=virtio" should be absolutely stable 
regardless of what we do to the virtio device model.  However, I want the 
flexibility to remove "-device virtio-blk-pci" and replace it with "-device 
virtio-pci,id=foo -device virtio-blk,bus=foo".

We would provide a means to enumerate supported devices so that things like 
libvirt could see that virtio-blk-pci is not valid in this new version but now 
there is a virtio-pci and virtio-blk device.

Regards,

Anthony Liguori

>