[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 01/27] qom: add the base Object class
Date: Thu, 22 Dec 2011 13:57:20 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

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 :-)


Anthony Liguori

I think maybe I'm not understanding the use case.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]