qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] QDev explicit constructors & destructors


From: Liviu Ionescu
Subject: Re: [Qemu-devel] [RFC] QDev explicit constructors & destructors
Date: Tue, 23 Jun 2015 23:10:40 +0300

> On 23 Jun 2015, at 21:31, Peter Crosthwaite <address@hidden> wrote:
> 
> I will review it on list and see if I can think of alternate
> construction sequence.

I suggest your review should start from use cases like this:

    DeviceState *dev = my_dev_alloc(NULL, TYPE_MYTYPE);
    my_dev_prop_set_bool(dev, "param", true);
    my_dev_construct(OBJECT(dev), NULL);
    my_dev_prop_set_uint32(dev, "xyz", 123);
    my_dev_realize(dev);

please ignore the fictional function names, and just assume that constructing 
the object requires a parameter that is given on the command line, so it does 
not exist statically at .instance_init time.

the point here is that "xyz" is an alias, created during construction time.

if we take out the construction step, the code would look like:

    DeviceState *dev = my_dev_alloc(NULL, TYPE_MYTYPE);
    my_dev_prop_set_bool(dev, "param", true);
    my_dev_prop_set_uint32(dev, "xyz", 123);
    my_dev_realize(dev);

since "xyz" must be an alias to an object that cannot be created at 
.instance_init, the alias itself cannot be created at .instance_init time, and 
setting "xyz" will fail.

another solution would look like:

    DeviceState *dev = my_dev_alloc(NULL, TYPE_MYTYPE);
    my_dev_prop_set_string(dev, "param", "something");
    my_dev_realize(dev);
    my_dev_prop_set_uint32(dev, "xyz", 123);

which obviously fails while trying to set the locked "xyz" property.

as suggested by Andreas, QOM prefers all objects to be created by default 
constructors (in .instance_init).

in this case the code might look like:

    DeviceState *dev;
    if (param_value)
      dev = my_dev_alloc(NULL, TYPE_MYTYPE1);
    else
      dev = my_dev_alloc(NULL, TYPE_MYTYPE2);
    my_dev_prop_set_uint32(dev, "xyz", 123);
    my_dev_realize(dev);

but, in my opinion, this is impractical for complex objects. 

for example instead of using a single "stm32-mcu" object parametrised with a 
capabilities structure, such a solution would require tens of separate objects 
for each existing MCU in a family, which is not realistic.


regards,

Liviu




reply via email to

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