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

[Liviu Ionescu]

> On 23 Jun 2015, at 13:39, Andreas Färber <address@hidden> wrote:
> 
> ... that spares indentation.

indentation? I'm not doing it manually, I just press a key combination in my 
Eclipse and indentation is done auto-magically.

> Please don't add new infrastructure with "qdev" in the name, qdev was
> the old device infrastructure that has been replaced with QOM;

I have difficulties to follow you. 

you mean qdev_* functions should no longer be used and all objects must be 
manipulated **only** with object_* functions?

is there a document mentioning this? the wiki page mentions them both, but does 
not visibly deprecate qdev.

> use
> "device" naming for any new APIs.

please provide a link to more details, I did not find any "device" naming API.

> But really, you should read up on the two discussions, a) when Anthony
> introduced QOM (several looong threads with Paolo, Avi and others)

could you provide more details to identify this thread? 

> and
> b) when I ran into the issue of virtual methods (start with the
> resulting documentation in object.h).

I read the documentation in object.h and I could not find an answer to my 
problem.

I need a clear method to instantiate multiple objects of the same class by 
providing multiple different parameters to the constructor.

your only explicit method to initialise instances is .instance_init and 
.instance_post_init, which do not take parameters.

the "realized" special property is another story, it is very confusing and 
abused to do the actual instance construction, which, in my opinion, is wrong 
and should be avoided.

the comments in qdev-core.h state "... devices must not create children during 
@realize; ..." and other restrictions:

* As an interim step, the #DeviceState:realized property is set by deprecated
* functions qdev_init() and qdev_init_nofail().
* In the future, devices will propagate this state change to their children
* and along busses they expose.
* The point in time will be deferred to machine creation, so that values
* set in @realize will not be introspectable beforehand. Therefore devices
* must not create children during @realize; they should initialize them via
* object_initialize() in their own #TypeInfo.instance_init and forward the
* realization events appropriately.

> 
> You seem to be opening a can of worms without understanding where we're
> coming from, how it's being used and where this is headed

any links to more info will be appreciated

> : QOM is not
> just a random C++-in-C framework.

no, it obviously is not C++ (what a pity), documentation is scarce, and, until 
I find out how to create multiple parametrised instances otherwise then in the 
realize() callback, I would say slightly dysfunctional framework.

> We've specifically banned pointers
> except for a handful by converting to link<> properties, and I see
> adding random opaque pointers to the generic constructor model - be it
> for devices or all objects - as a clear no-no.

in my code I pass all constructor parameters via properties, the 'void *data' 
was added to the prototype for completeness, but can be removed without 
problems.

> Look at how QOM objects
> are being instantiated from QMP commands or config files as a hint to
> what you're missing here

I did a search for 'object_' but could not find any relevant use cases. :-(

> If you do in some local case want to pass local C data to the object,
> you can already do so via .class_data if all instances are the same,

no, they are not.

> If I'm not seeing the problem, you'll need to explain better why
> class_init + instance_init + properties + realize doesn't fit your use case.

- class_init is out of question for multiple instances;
- instance_init is too early, since no parameters are available
- realize is too late, since it locks the object and no further properties can 
be set.

the general use case is

- alloc or use a statically allocated area
- set properties that represent constructor parameters
- call the constructor; based on the given parameters, dynamically create 
children objects, dynamically create properties, dynamically create property 
aliases from children objects to the main object
- set more properties to the newly added dynamic properties
- freeze the object configuration (via the notoriously confusing finalize())

as far as I understood the qom/qdev framework, the only way this can be done is 
by using a custom function (I called it .construct) to act as instance 
constructor. it does not need to take parameters, properties are fine.

my new proposal would be to add 

        void (*construct)(Object *obj)

to the Object class, that would greatly simplify usage compared to defining it 
in each derived class.

if adding this member to the Object class is not possible, I'll probably define 
MyObject, with this member in, and derive all classes from it. but it would be 
a pity...

> That said, your efforts of simplifying STM32 instantiation are
> appreciated.

thank you! :-)

I would still need some help to start it properly. 

I have tens of MCUs on my list, and tens of boards; maintaining them would be 
very difficult if not started properly.

> I've been wanting to add an F429 Discovery machine for my
> Linux port.

I already have a 'STM32F429I-Discovery' board on my list, my initial plan is to 
grow it to the point it blinks a LED, and then we'll extend it to suit your 
needs.


regards,

Liviu