From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RW7VE-0001Bp-2l for qemu-devel@nongnu.org; Thu, 01 Dec 2011 09:20:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RW7VC-0004Xt-RU for qemu-devel@nongnu.org; Thu, 01 Dec 2011 09:20:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RW7VC-0004Xh-HZ for qemu-devel@nongnu.org; Thu, 01 Dec 2011 09:20:42 -0500 Message-ID: <4ED78D33.5040206@redhat.com> Date: Thu, 01 Dec 2011 16:20:35 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1322687028-29714-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: <1322687028-29714-1-git-send-email-aliguori@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/18] qom: dynamic properties and composition tree List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Peter Maydell , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino 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? 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. -- error compiling committee.c: too many arguments to function