Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Markus Armbruster]

Copying Andreas in case he has further advice.

Peter Crosthwaite <address@hidden> writes:

> On Wed, Jun 3, 2015 at 5:31 AM, Liviu Ionescu <address@hidden> wrote:
>>
>>> On 01 Jun 2015, at 23:36, Liviu Ionescu <address@hidden> wrote:
>>>
>>> ... I just pushed a preliminary version where all STM32 MCUs and
>>> STM32 related boards use the new framework.
>>
>> please disregard the current version, I'm already re-working the
>> code to be more compliant with the (quite complicated) object
>> infrastructure.
>>
>> btw, except from various other pieces of code, more or less
>> up-to-date, is there any document explaining what is the recommended
>> way of using these objects?
>>
>> at least the confusing 'realize' mechanism is it explained somewhere?
>>
>
> http://wiki.qemu.org/QOMConventions
>
> but that doesn't really cover your question.
>
> Some of my rules of thumb.
>
> 1: For container objects, realize is often just a recursive call of
> realize for the contained. It may set properties on the way. see
> hw/arm/xlnx-zynqmp for a recent example.
> 2: Data structure creation should generally go in the init. If it
> depends on a property (e.g. to size an array) then you can delay to
> realize or do it in a property setter callback.
> 3: If it has a user visible failure path it goes in realize
> 4: When in doubt and if it is possible. do things in init, not realize.
> 5: External interface connection is usually realize (e.g. connecting a
> uart or network)
> 6: Do not have any device state modifications in realize. A common
> mistake is to put hardware reset behavior in realize (e.g. initing
> registers to their reset value). Use the DeviceClass::reset callback
> for this.
> 7: When I say init, I mean the object instance_init callback, do not
> use the depracated SysBusDevice::init callback.