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.