Copying Andreas in case he has further advice. Peter Crosthwaite <peter.crosthwa...@xilinx.com> writes:
> On Wed, Jun 3, 2015 at 5:31 AM, Liviu Ionescu <i...@livius.net> wrote: >> >>> On 01 Jun 2015, at 23:36, Liviu Ionescu <i...@livius.net> 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.
