[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 00/18] qom: dynamic properties and composition tree
Date: Thu, 01 Dec 2011 08:42:00 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: 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
     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:


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


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]