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

[Anthony Liguori]

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:
> >
> > address@hidden:~/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:
> >
> > address@hidden:~/git/qemu/QMP$ ./qom-list /
> > peripheral/
> > i440fx/
> > address@hidden:~/git/qemu/QMP$ ./qom-list /i440fx/
> > piix3/
> > address@hidden:~/git/qemu/QMP$ ./qom-list /i440fx/piix3
> > rtc/
> > address@hidden:~/git/qemu/QMP$ ./qom-list /i440fx/piix3/rtc
> > date
> > base_year
> > address@hidden:~/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

>