qemu-devel
[Top][All Lists]
Advanced

[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: Kevin O'Connor
Subject: Re: [Qemu-devel] [PATCH 01/27] qom: add the base Object class
Date: Thu, 22 Dec 2011 13:00:18 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

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