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