> On 23 Jun 2015, at 21:31, Peter Crosthwaite <peter.crosthwa...@xilinx.com>
> 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
