Hi Liviu,
Am 15.06.2015 um 15:35 schrieb Liviu Ionescu:
>> On 15 Jun 2015, at 13:48, Liviu Ionescu <i...@livius.net> wrote:
>>
>> ... One natural solution would be to add an explicit constructor, like in
>> C++.
>
> if this solution is considered too complicated, it might also be possible to
> arrange for the constructor data to be passed to the existing .instance_init
> call.
>
> the use case would be even simpler:
>
> DeviceState *mcu = qdev_create_with_data(NULL, TYPE_STM32F103RB,
> &constructor_data);
> {
> /* Set various properties. */
> qdev_prop_set_uint32(mcu, "hse-freq-hz", 8000000); /* 8.0 MHz */
> qdev_prop_set_uint32(mcu, "lse-freq-hz", 32768); /* 32 KHz */
> }
These {...} blocks have no justification at all, so please avoid them
for the sake of readability. Just use empty lines for grouping, that
spares indentation.
> qdev_realize(mcu); /* QDev specific step */
[snip]
Please don't add new infrastructure with "qdev" in the name, qdev was
the old device infrastructure that has been replaced with QOM; use
"device" naming for any new APIs.
But really, you should read up on the two discussions, a) when Anthony
introduced QOM (several looong threads with Paolo, Avi and others) and
b) when I ran into the issue of virtual methods (start with the
resulting documentation in object.h).
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: QOM is not
just a random C++-in-C 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. Look at how QOM objects
are being instantiated from QMP commands or config files as a hint to
what you're missing here (apart from CC'ing the right maintainers ;)).
(Note that quite similarly Linux has been replacing platform data
structs with Device Tree nodes.)
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, as
in your case of a single MCU on a board probably.
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.
That said, your efforts of simplifying STM32 instantiation are
appreciated. I've been wanting to add an F429 Discovery machine for my
Linux port.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)
