>From reply of the upstream patch: https://lore.kernel.org/linux-arm-kernel/[email protected]/
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 <[email protected]> 于2021年2月2日周二 下午7:39写道： > > On Tue, Feb 02, 2021 at 07:58:09AM +0800, Tianling Shen wrote: > > From: Sumit Gupta <[email protected]> > > > > 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/[email protected]/ > > The thread above already has arguments against this patch. Has anything > changed since? > > -- > Catalin
