From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXalM-0006cJ-SQ for qemu-devel@nongnu.org; Mon, 05 Dec 2011 10:47:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXalI-0001h2-24 for qemu-devel@nongnu.org; Mon, 05 Dec 2011 10:47:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXalH-0001gw-Ow for qemu-devel@nongnu.org; Mon, 05 Dec 2011 10:47:24 -0500 Message-ID: <4EDCE787.8070306@redhat.com> Date: Mon, 05 Dec 2011 16:47:19 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <4ED98C06.5040405@codemonkey.ws> <4EDA3104.8030304@redhat.com> <4EDA95ED.6030706@codemonkey.ws> <4EDBDFC7.3090206@codemonkey.ws> <4EDC946A.3090702@redhat.com> <4EDCD6EA.7090500@codemonkey.ws> In-Reply-To: <4EDCD6EA.7090500@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 00/18] qom: dynamic properties and composition tree (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On 12/05/2011 03:36 PM, Anthony Liguori wrote: > It's to support method inheritance. In qdev, the various DeviceInfo > structures correspond roughly to the class of the object. When you > create an ISADeviceInfo (the ISA subclass), you declare it statically. > > Any methods you aren't overriding are going to be initialized to zero. > You want those methods to inherit their values from the base class. To > do this in qdev, you have to introduce a base-class specific > registration function (isa_qdev_register). > > There's not a lot of discipline in how these functions are implemented > and generally makes type registration more complicated as you have to > understand what methods get overridden. Yeah, that's true. I think in general our class hierarchy is shallow enough that we could live with that, but I appreciate that dynamic initialization has advantages. > links are nullable and usually start out as NULL. > > childs are not nullable. I can't really think of a reason why they > should be nullable. What are you thinking here? Ok, I understand now better what children are. > I've thought a lot about bus properties. I've looked at a lot of code at > this point and for the most part, I think that the reason they even > exist is because we can't inherit a default set of properties. > > SCSI is a good example. The bus properties really make more sense as > SCSIDevice properties that are inherited. Yeah, bus properties *are* most of the time properties that you add to the abstract class, so... > I dislike these properties in the first place, but I'd like to find a > way to convert everything to the QOM type system before we start > rearchitecting how hotplug works. ... just change them to properties on the abstract class. >> Perhaps hidden with some macro that lets me just write >> SCSI_BUS_INTERFACE(dev), but that's the idea; such a lookup function is >> pretty much what all object models do. GObject has >> G_TYPE_INSTANCE_GET_INTERFACE, COM/XPCOM has QueryInterface, etc. >> >> If I understood everything so far, then here is my question. Are >> interfaces properties? > > No. A device is-a interface. Hopefully the above example will make it > more clear. No, but I'm confident that there will be a sane way to access the list of interfaces that you embed in the Object type. :) >> That's not what I meant. The legacy<> namespace splits the set of QOM >> properties in two parts, sane ones and legacy ones. That's wrong, >> because the old broken interface remains there. Worse, it remains >> there as user-visible API in the JSON etc., and it will remain forever >> since we >> cannot get rid of -device overnight. >> >> What I suggested is to provide two implementations for each old-style >> property: an old string-based one (used for -device etc.) and a modern >> visitor-based one (used for qom_*). In other words, old-style >> properties would expose both a print/parse legacy interface, and a sane >> get/set visitor interface. No need for a legacy<> namespace, because >> new-style consumers would not see the old-style string ABI. > > Yeah, I'd like to do something like this but I'm in no rush. I agree > that when we declare QOM as a supported interface, we should have > replacements for anything that's in the legacy<> space. That may be from > some magic Property tricks where we introduce Visitor to parse/print or > because we introduce new and improved properties. Yeah, extending Property looks like a feasible plan. The get/set pair is an adaptor between JSON/Visitor-type data and C struct fields, the parse/print pair is an adaptor between strings and C struct fields. > Maybe now is the right time to rename the legacy properties to all be > prefixed with qdev-? That way we don't need to introduce two different > types for a single property. Why do you need such a prefix? Paolo