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

[Philippe Mathieu-Daudé]

On 2/13/20 3:32 PM, Peter Maydell wrote:
> On Thu, 13 Feb 2020 at 14:16, Philippe Mathieu-Daudé <address@hidden> 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/address@hidden/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.