Closed dpogue closed 1 year ago
How far back does sysctl work? Wondering if this should be a runtime check instead of a compile time check. But if the modern Mac client doesn't fall along a sysctl compatibility boundary I'd be fine with compile time.
sysctl
itself goes way back (probably to 10.0, since it exists in FreeBSD), but the machdep
values don't go as far back as 10.5 (or maybe they do but only on Intel)
What benefit do we get by supporting both the new sysctl
API and the older mach one instead of just the latter?
On newer machines, the old mach call just returns "ARM64E" for the CPU name instead of "Apple M1 Pro" 😒
Also, using the mach stuff is... not deprecated, but let's say discouraged... sysctl is the supported way to get this information
Yeah, anything Mach tends to be in a discouraged state these days.
I'm fine with the ARM64E return right now. It would be nice to get the CPU name... but if we log GPU details the GPU name would let us know the exact SoC.
Does the sysctl approach default to on? In since a hypothetical PPC client would likely be the only place the fallback is needed I'd want to make sure the right path for most builds is the default.
Does the sysctl approach default to on? In since a hypothetical PPC client would likely be the only place the fallback is needed I'd want to make sure the right path for most builds is the default.
HAVE_SYSCTL
should default to on for macOS, since that's what we're using to get the RAM values on all macOS versions
@colincornaby does this look good to you?
Pinging @colincornaby for reaction
This looks good to me.
macOS doesn't support CPUID, so previously all macOS CPUs were being reported as "Unknown".
On newer versions, we can get the CPU vendor string from
sysctl
, and on very old versions we can look it up from the mach host info.Results of plSystemInfo on Ventura:
Results of plSystemInfo on Catalina:
Results of plSystemInfo on Leopard: