Re: [PATCH v3 12/13] hw/arm/raspi: Use a unique raspi_machine_class_init() method

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 2/13/20 3:32 PM, Peter Maydell wrote:
> On Thu, 13 Feb 2020 at 14:16, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>> On 2/13/20 2:59 PM, Peter Maydell wrote:
>>> The natural way to implement this is to have the .class_data
>>> be a pointer to a struct which is in an array and defines
>>> relevant per-class stuff, the same way we do in
>>> bcm2836_register_types(). That way the struct can indicate
>>> both the board revision number and also "is this a legacy
>>> board that needs transaction-failures disabled?".
>>
>> IIUC Igor insists explaining that he doesn't accept anymore a
>> ".class_data pointer to a struct which is in an array and defines
>> relevant per-class stuff" and we should not use this pattern anymore.
> 
> Huh? How else would you do this? I'm kinda dubious about the
> pattern this patch series uses of just stuffing a 32-bit board
> ID number into the class_data field, to be honest -- I let that
> pass partly not to hold up the series but partly because I
> expect that we'll need to turn it back into a proper pointer
> to a data struct soonish.

https://www.mail-archive.com/qemu-devel@nongnu.org/msg678305.html

Igor> we sometimes use .class_data when creating many
       derived types (typical example CPU types (x86))
       where it's impractical to code leaf class_init
       functions. I'd use .class_data in cases where I
       can't get away with explicit .class_init

Which I understand as:

- avoid .class_data (pointers to structures)
- explicitly set ObjectClass::fields in .class_init()
   by open-coding all.