Re: [Qemu-devel] [PATCH 01/27] qom: add the base Object class

[Anthony Liguori <anthony@codemonkey.ws>]

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
>