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

[Anthony Liguori <aliguori@us.ibm.com>]

On 12/01/2011 08:20 AM, Avi Kivity wrote:
> On 11/30/2011 11:03 PM, Anthony Liguori wrote:
>> This is a follow up to my previous series to get us started in the QOM
>> direction.  A few things are different this time around.  Most notably:
>>
>>   1) Devices no longer have names.  Instead, path names are always used to
>>      identify devices.
>>
>>   2) In order to support (1), dynamic properties are now supported.
>>
>>   3) The concept of a "root device" has been introduced.  The root device is
>>      roughly modelling the motherboard of a machine.  This type is a container
>>      type and it's best to think of it as something like a PCB board I guess.
>>
>> To try it out, here's an example session:
>>
>> Launch:
>>
>> anthony@titi:~/build/qemu$ x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img -snapshot -device virtio-balloon-pci,id=foo -qmp unix:/tmp/server.sock,server,nowait
>>
>> Explore the object model:
>>
>> anthony@titi:~/git/qemu/QMP$ ./qom-list /
>> peripheral/
>> i440fx/
>> anthony@titi:~/git/qemu/QMP$ ./qom-list /i440fx/
>> piix3/
>> anthony@titi:~/git/qemu/QMP$ ./qom-list /i440fx/piix3
>> rtc/
>> anthony@titi:~/git/qemu/QMP$ ./qom-list /i440fx/piix3/rtc
>> date
>> base_year
>> anthony@titi:~/git/qemu/QMP$ ./qom-get /i440fx/piix3/rtc.date
>> tm_sec: 33
>> tm_hour: 21
>> tm_mday: 30
>> tm_year: 111
>> tm_mon: 10
>> tm_min: 2
>>
>
> So all of these become ABIs, right?

At first, no.  I marked all of these QMP functions as experimental specifically 
to avoid introducing a new ABI.  I want to give us some time to work out things 
out a bit more.  But yes, this will eventually become an ABI.

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

That turns the problem into something that requires less cleverness.

Regards,

Anthony Liguori

>