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.
I think maybe I'm not understanding the use case.
Cheers,
-Kevin
