qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
Date: Mon, 11 Jun 2012 10:04:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]