Pardon my naive questions; this is my first time handling non-userland code.

Why aren't you using the model property from the device tree?

I agree with Andrew... the approach here for FDT-based systems should be to use the model string from the FDT data. Note that that usually doesn't tell you anything about the CPU at all, it tells you about the overall board/system. I don't think that's a problem, it's just a bit different than the info available on x86 systems.

Replying to myself here... now I think I've changed my mind. Looking at all the other arches that support a hw.model sysctl (everything except arm and riscv), they all provide the specific CPU model, not an overall machine/system model; it's just a historical poor choice of name that we're stuck with.

So all in all, I agree with the originator's idea that the sysctl could be implemented in identcpu-v6.c using the existing code that prints the cpu info. That would give us a string like "ARM Cortex-A9 r2p10 (ECO: 0x00000000)".

It would actually be nice to export the board/system model string from FDT data as well, but we'd have to make a new hw.<something> oid name for it since the obvious name was already taken to mean "cpu type".

In D14465#304163, @ian wrote:

It would actually be nice to export the board/system model string from FDT data as well, but we'd have to make a new hw.<something> oid name for it since the obvious name was already taken to mean "cpu type".

I once had a hw.board that I filled in from the FDT data. I thought I'd committed it, but it's not in the tree... I wonder which would be easier to do: find it on what might even be disks at Ian's employer and update it, or just redo from scratch... :)

I am trying to reuse the existing core detection in sys/arm/arm/identcpu-v6.c:288 for filling out the OID.

@imp, does that 'changing to char *' still stands? Should I use malloc when filling that OID, or just leave it as is (char cpu_model[64])?

Also, as @andrew and @ian suggested, I am thinking about this: first set the OID with what identify_arm_cpu() gives us, then later when FDT is available (inside initarm()?) add the board specific core name to the OID.

The only question is: is this an acceptable, legitimate approach?

All the existing arches use a static string array of either 64, 80, or 128 bytes. All the current arm models in the table, if formatted just like they print out now in dmesg, will fit in 44 bytes. My vote would be for the simplicity of static char cpu_model[64] and use snprintf() to format it for use in both printing in dmesg and for the sysctl.

I think we should handle the fdt-provided info with new OIDs. Hopefully we can do so in the common platform code somewhere.

On irc, imp suggested "hw.board" for the info from fdt's root-node model= property. But that's going to give a marketing name for the whole board, like Raspberry Pi or Wandboard, not the SoC name. I can't find any documentation about a standard property that gives the SoC name. It looks like it's often present as one of the strings in the compatible= property of the root node, but even that may not be universal.

In D14465#304593, @imp wrote:

my only concern is with 64-bytes being long enough.

Ian reports on IRC that 44 bytes is enough for everything, so 64 should give us a good buffer.