From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55672) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rdolc-0003mr-UD for qemu-devel@nongnu.org; Thu, 22 Dec 2011 14:57:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rdolb-0003QH-0t for qemu-devel@nongnu.org; Thu, 22 Dec 2011 14:57:28 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:60720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rdola-0003Q7-Sk for qemu-devel@nongnu.org; Thu, 22 Dec 2011 14:57:26 -0500 Received: by iagj37 with SMTP id j37so15856855iag.4 for ; Thu, 22 Dec 2011 11:57:25 -0800 (PST) Message-ID: <4EF38BA0.1090706@codemonkey.ws> Date: Thu, 22 Dec 2011 13:57:20 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1324399916-21315-1-git-send-email-aliguori@us.ibm.com> <1324399916-21315-2-git-send-email-aliguori@us.ibm.com> <4EF1E094.6080500@redhat.com> <4EF1EEA4.40209@us.ibm.com> <20111222172531.GA24638@morn.localdomain> <4EF36BB4.1070405@codemonkey.ws> <20111222180018.GA29733@morn.localdomain> In-Reply-To: <20111222180018.GA29733@morn.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/27] qom: add the base Object class List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: Paolo Bonzini , Anthony Liguori , qemu-devel@nongnu.org, Markus Armbruster On 12/22/2011 12:00 PM, Kevin O'Connor wrote: > On Thu, Dec 22, 2011 at 11:41:08AM -0600, Anthony Liguori wrote: >> On 12/22/2011 11:25 AM, Kevin O'Connor wrote: >>> On Wed, Dec 21, 2011 at 08:35:16AM -0600, Anthony Liguori wrote: >>>> I used a symbolic type name to avoid the problem of dependencies. >>>> In order to create a type in gobject, you have to reference the >>>> parent's GType which usually means you have to call the _get_type() >>>> function which acts as a singleton which registers the type. >>>> >>>> Since you have to specify the parent via a function call, you can't >>>> define the type in a unit-level static structure which I viewed as a >>>> critical requirement. >>> >>> Why not declare types with something like the following: >>> >>> TypeInfo my_device_info = { >>> .name = "my-device", >>> .parentinfo =&device_info, >>> .instance_size = sizeof(MyDevice), >>> }; >>> >>> That is, instead of looking up the TypeImpl via a string, lookup the >>> TypeImpl via the address of the TypeInfo. (Or possibly store a >>> pointer to TypeImpl in TypeInfo during registration.) >>> >>> Module order shouldn't matter - all the info needed to register the >>> parent is there so it can be registered during first use. >> >> The only problem with this is that if a .so implements the type, it >> means that you have to have a way to figure out the dependency order >> as you load the modules. >> >> OTOH, with the current approach, you can dlopen() all of the modules >> and register the types, and then when the first object is >> instantiated, that's when the type resolution will happen. > > If "device_info" is a symbol in basedevice.so and mymodule.so has a > reference to "device_info", wont dlopen("mymodule.so") automatically > bring in basedevice.so? > > If not, then it seems like things would get sticky anyway - if the > underlying struct in mymodule.so is defined as: > > typedef struct MyDevice > { > DeviceState parent; > > int reg0, reg1, reg2; > } MyDevice; > > it would seem likely that mymodule.so would have assorted references > to basedevice.so for calls on mydev.parent. Yes, thinking about it, I think you're correct that .parent could refer to some sort of type handle. But I think it's a bit nicer to have a string identify the parent type than an extern struct. I guess it's more a matter of taste than anything else :-) Regards, Anthony Liguori > I think maybe I'm not understanding the use case. > > Cheers, > -Kevin >