From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RW892-0008BT-5G for qemu-devel@nongnu.org; Thu, 01 Dec 2011 10:01:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RW88w-0007gC-9z for qemu-devel@nongnu.org; Thu, 01 Dec 2011 10:01:52 -0500 Received: from mail-yw0-f45.google.com ([209.85.213.45]:40845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RW88w-0007fF-7P for qemu-devel@nongnu.org; Thu, 01 Dec 2011 10:01:46 -0500 Received: by ywe9 with SMTP id 9so2487659ywe.4 for ; Thu, 01 Dec 2011 07:01:40 -0800 (PST) Message-ID: <4ED796D1.70301@codemonkey.ws> Date: Thu, 01 Dec 2011 09:01:37 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1322687028-29714-1-git-send-email-aliguori@us.ibm.com> <4ED78D33.5040206@redhat.com> <4ED79238.9050504@us.ibm.com> <4ED793D8.9000202@redhat.com> In-Reply-To: <4ED793D8.9000202@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Avi Kivity Cc: Kevin Wolf , Peter Maydell , Anthony Liguori , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino On 12/01/2011 08:48 AM, Avi Kivity wrote: > On 12/01/2011 04:42 PM, Anthony Liguori wrote: >> >>> >>> 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. >> > > Does this force anyone who wants a stable ABI to use this library? > > I don't have a good picture of this library. If FooState has a bar > propery, do you generate qemu_foo_get_bar() and qemu_foo_set_bar() > accessors? This is all extremely low level stuff. My view is that if you are a user that cares about backwards compatibility, you probably don't want all of this low level stuff in the first place. I think we need to provide two classes of interfaces. A low-level interface that only something like libvirt would consume that is not 100% backwards compatible and a higher-level interface that less sophisticated tools would consume. If we provide a not 100% backwards compatible interface, then we would also need to provide a good introspection/capabilities mechanism so that something like libvirt could find out whether a feature was available or whether a device has changed significantly. To be very clear, I think "-drive if=virtio" should be absolutely stable regardless of what we do to the virtio device model. However, I want the flexibility to remove "-device virtio-blk-pci" and replace it with "-device virtio-pci,id=foo -device virtio-blk,bus=foo". We would provide a means to enumerate supported devices so that things like libvirt could see that virtio-blk-pci is not valid in this new version but now there is a virtio-pci and virtio-blk device. Regards, Anthony Liguori >