A Nifty Way To Access Linux Memory/RAM Information

[coder]

Every year brings at least 6 new platforms - (desktop + mobile + server/workstation) * 2 main x86 processor manufacturers * 1 generation per year

Just gonna nit-pick on this point. AMD didn't release any new desktop platform in 2023. They also typically skip a year between ThreadRipper and EPYC platform changes. Intel also does 2-year cadence on server chipsets and desktop sockets. The changes between desktop chipsets of the same socket are probably very minor.

Similarly, Intel and AMD's high-end mobile are the same as their desktops. So, that just adds a couple mobile CPU releases for them, each. I think Intel only had two strictly-mobile dies (U-series and P-series), across both Gen 12 and Gen 13. For AMD, there was the Ryzen 6000 (whatever it was codenamed) and then Phonenix, which is getting refreshed as 8000-series.

It's still a lot, but I think you're being a little hyperbolic.

which must be tested one by one,

Or just code it to the specs, put it out there, and let people report bugs if they find any.

Intel and AMD have been churning new generations at a rate a bit higher than 1 per year, or tend to produce two families of server platforms (Zen 4 vs. Zen 4c,

They both use the same socket and I thought used the same I/O die. Do you know differently?

Okay, there was Siena - different socket and probably I/O die.

[debrouxl]

I stand corrected about a somewhat lower rate of new chipsets than I wrote. It still adds to the amount of work for existing chipsets.
When Sam adds IMC support for the first mobile platforms, we'll see the differences - if any - with desktop platforms of the same generation. I'm not going to bet that the changes are just a matter of adding a case to match a device with an existing driver, without having to special-case anything
Adding support for server processor IMCs, even only the ones corresponding to the current memtest86+ drivers, will require changes across the board, since these platforms support more than 2 memory channels, as we both know.

Or just code it to the specs, put it out there, and let people report bugs if they find any.

Well, that's quite adventurous for code which pokes processor MSRs and/or chipset MMIO
Sam always dogfoods his code of that kind before releasing it to the general public, and he's right to do it. Despite his best efforts on the relatively large collection of hardware he has access to, harmless bugs still happen in weird configurations, as shown by the recent https://github.com/memtest86plus/mem...lus/issues/375 .
We'll see when he can find some time to get back to his "not really stable" prototype code for accessing SNB+ Xeon-E/-EP SMBus controllers ( https://github.com/memtest86plus/mem...plus/issues/65 ). IMC and EDAC are bigger fish to fry, plus supporting Xeons will open even wider the door to platforms with more than 8 RAM sticks...