[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 00/18] qom: dynamic properties and composition t
Re: [Qemu-devel] [PATCH 00/18] qom: dynamic properties and composition tree
Thu, 01 Dec 2011 08:42:00 -0600
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
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
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:
address@hidden:~/build/qemu$ x86_64-softmmu/qemu-system-x86_64 -hda
~/images/linux.img -snapshot -device virtio-balloon-pci,id=foo -qmp
Explore the object model:
address@hidden:~/git/qemu/QMP$ ./qom-list /
address@hidden:~/git/qemu/QMP$ ./qom-list /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-get /i440fx/piix3/rtc.date
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
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.