Re: [RESENT PATCH] arm64: cpuinfo: Add "model name" in /proc/cpuinfo for 64bit tasks also

[CN_SZTL <cnsztl@gmail.com>]

From reply of the upstream patch:
https://lore.kernel.org/linux-arm-kernel/20160629195137.GA142854@google.com/

Brian Norris wrote:
```
What's the status on this patch? The previous patch (which was accepted
already) is indeed confusing, because ARM32 processes on an ARM64 system
are not necessarily setting PER_LINUX32.

I'm also curious, why was 'model name' removed from ARM64 in the first
place? Plenty of other architectures support a similar property, and
it's useful for some tools that already parse this, such as coreutils
`uname -p` on Gentoo (and presumably others -- my Ubuntu machine must be
similarly patched, as it supports `uname -p` on x86_64).
```

However, the restriction seems not so fairly:
Firstly, the ARM32, which is the purpose of the author making the code
works for,
with this restriction, even doesn't work in some cases.
Secondly, as the code works for both ARM32 and ARM64, what's the
significance of setting
such a restriction?
Thirdly, there're many tools and systems which parse this, so the
field actually makes sense.
For example, like what we have written in cpuinfo.c#L148, "Give glibc
what it expects".

So, in my option, it's fine to remove the restriction and let it work
for both architectures.


Catalin Marinas <catalin.marinas@arm.com> 于2021年2月2日周二 下午7:39写道：
>
> On Tue, Feb 02, 2021 at 07:58:09AM +0800, Tianling Shen wrote:
> > From: Sumit Gupta <sumitg@nvidia.com>
> >
> > Removed restriction of displaying model name for 32 bit tasks only.
> > This can be used for 64 bit tasks as well, and it's useful for some
> > tools that already parse this, such as coreutils `uname -p`, Ubuntu
> > model name display etc.
> >
> > It should be like this:
> > ```
> > $ cat '/proc/cpuinfo' | grep 'model name' | head -n 1
> > model name : ARMv8 Processor rev X (v8l)
> > ```
> >
> > Link: https://lore.kernel.org/lkml/1472461345-28219-1-git-send-email-sumitg@nvidia.com/
>
> The thread above already has arguments against this patch. Has anything
> changed since?
>
> --
> Catalin