[Top][All Lists]

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

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

From: Philippe Mathieu-Daudé
Subject: Re: [PATCH v3 12/13] hw/arm/raspi: Use a unique raspi_machine_class_init() method
Date: Thu, 13 Feb 2020 16:33:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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.


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.

reply via email to

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