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

[Liviu Ionescu]

> On 23 Jun 2015, at 17:25, Andreas Färber <address@hidden> wrote:
> 
> ... I honestly don't understand what you're arguing here... Your
> code examples are not telling.

:-(

> Are you maybe missing that there are dynamic QOM properties in addition
> to the qdev properties you use in your examples?

        /* Alias RCC properties to MCU, to hide internal details. */
        object_property_add_alias(obj, "hse-freq-hz", OBJECT(dev),
                "hse-freq-hz", NULL);
        object_property_add_alias(obj, "lse-freq-hz", OBJECT(dev),
                "lse-freq-hz", NULL);

I think that exactly the existence of dynamic QOM properties (aliases in my use 
case) is the reason why objects cannot be constructed by realize(), which is 
too late, since the newly created aliases will point to properties that will be 
frozen before having a chance to be used outside the call.

> And that you can design your class hierarchies so that you don't need
> the parametrized instantiation in the first place?

I agree that properly designed class hierarchies with virtual calls are 
preferred to parametrised instantiation, but in non-OO languages the effort to 
define the classes makes this impractical.

for example, for the STM32 MCUs, there are F0, F1, F2, F3, F4, F7, L0, L1 main 
families, each with several sub-families (F1 has low, medium, high, extra, 
connectivity, etc), it is not realistic to define QOM types for each one, 
especially when the differences are small, like some changed bits in a 
register. so my current decision was to implement all similar peripherals in a 
single class for all families, and, based on some flags in a capabilities 
structure, to adjust the behaviour for each device.

but I might be wrong.

> our established concept of two-phase constructors.

I fully agree with the two-phase constructors approach, but I'm not convinced 
the second step should be realize(), because I just ran into a case (dynamic 
QOM aliases) when I could not make it work.

> If other contributors see a need for changes - and I have seen no
> contributor seconding any of your suggestions yet

see below:

> On 14 Jun 2015, at 04:49, Peter Crosthwaite <address@hidden> wrote:
> 
> Infact, I have an application of constructor arugments myself. This is
> for the ARM A9 MPCore container where the number of CPUs is variable
> per-instance. Same problem as you are facing, realize is too late,
> init is too early.

I'm convinced there are other cases too, especially for complex objects.

but if you do not see any issues with the existing design, ok, no problem, I'll 
find a workaround.

we'll stop this thread here, thank you for your time, 


Liviu