Questions about /proc/cpuinfo for arch-ARM - CAS-149046-Y1H3T8
maz at kernel.org
Mon Jan 20 01:41:59 PST 2020
On 2020-01-20 10:24, Steven Miao wrote:
> CC arm mailing list. Someone know the whole history may have a better
> From: Support-Software <mailto:support-software at arm.com>
> Sent: Monday, January 20, 2020 5:17 PM
> To: Tao Zeng <mailto:prime.zeng at hisilicon.com>
> Cc: Mark Rutland <mailto:Mark.Rutland at arm.com>
> Subject: Re: Questions about /proc/cpuinfo for arch-ARM -
> From Steven Miao - Arm Partner Enablement Group
> Please quote case reference number
> in any further emails to us on this subject.
> Hi Tao,
>> 1. Since /proc/cpuinfo is treated as ABI, so where can I find the
>> specification? Or is there any docs
>> to describe the details? Or it is just some applications who have
>> already token it?
> I think it is just de-facto ABI legacy application are relying on,
> there's no such specification.
>> You know that, in x86, /proc/cpuinfo provide really good user
>> what we want to do is providing the same or even better user
Tao: And by "better user experience", you mean breaking existing
I'm sure users will enjoy the "improvement".
> We should add new stuff to /sys/, don't add new things to /proc. On
> x86 these strings are acquired from the CPU itself, via CPUID
> instructions, which means that it works for future CPUs. For ARM
> systems, we have no consistent way of acquiring a model name from a
> CPU itself. If users who want to decode MIDRs are going to have to use
> userspace tools.
> Changing current cpuinfo:
> - it breaks existing applications
> - it is unmaintainable in the long run
> - we can already get cpu information by dmidecode, lscpu, lshw...
Exactly. The subject has been rehashed to death, and is not up for
discussion anymore. /proc/cpuinfo is ABI, which means its format is
forever immutable. Userspace has all the required tools at its disposal.
Jazz is not dead. It just smells funny...
More information about the linux-arm-kernel