Am 11.06.2012 09:56, schrieb Andreas Färber: > Am 11.06.2012 09:20, schrieb Paolo Bonzini: >> Il 11/06/2012 09:13, Andreas Färber ha scritto: >>>>>>> +The first step is to move your device struct definition to a header >>>>>>> file. This >>>>>>> +header file should only contain the struct definition and any >>>>>>> preprocessor >>>>>>> +declarations you need to define the structure. This header file will >>>>>>> act as >>>>>>> +the source for the QC IDL compiler. >>>>> >>>>> I don't think this is a fantastic idea -- the device struct should be >>>>> private to the device, and having it in a standalone header file is >>>>> asking for users of the device to illicitly include it and access >>>>> internals that they shouldn't. >>> But that is exactly where realize is headed. PCIBus, a9mp_priv etc. >>> structs will need to be made public so that they can be embedded. >> >> I thought that was just a convenience choice, not a necessity. The >> children objects could just as well be heap-allocated. > > In that case we'd need to change the instance_init signature. As far as > I've understood from our discussions with Anthony, realize must not > allocate new objects because that may collide with the recursive realize > model, and instance_init is not supposed to fail. Thus the in-place init > demonstrated for i440fx and now adopted for prep_pci and my tegra2. > Saying "the device struct should be private to the device" leaves > virtually no choice, whether for convenience or necessity, and requires > also suggesting a design solution for QOM initialization.
Forgot to mention that this has nothing to do with child<> properties. It's about composition, i.e. instantiating on object without needing to know about its inner structure - paradoxically this needs that inner structure to be exposed even if not accessed. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
