Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <1583908414-22858-1-git-send-email-yangtiezhu@loongson.cn>
 <CAOLZvyHEnnpWWhEAWx9RZASVjjQ=6HTREqwY+LK0hm=J4Wd8Xg@mail.gmail.com>
 <788597FA-6AD6-4218-886F-35C0916EA3F2@flygoat.com> <alpine.LFD.2.21.2003202109190.2689954@eddie.linux-mips.org>
In-Reply-To: <alpine.LFD.2.21.2003202109190.2689954@eddie.linux-mips.org>
From:   YunQiang Su <wzssyqa@gmail.com>
Date:   Sat, 21 Mar 2020 09:20:29 +0800
Message-ID: <CAKcpw6W=nVWGVkTi2ub82THUe09PGxHR1x9dSDW5A6sYnYGTUg@mail.gmail.com>
Subject: Re: [PATCH] MIPS: Loongson: Add model name to /proc/cpuinfo
To:     "Maciej W. Rozycki" <macro@linux-mips.org>
Cc:     Jiaxun Yang <jiaxun.yang@flygoat.com>,
        Manuel Lauss <manuel.lauss@gmail.com>,
        Tiezhu Yang <yangtiezhu@loongson.cn>,
        Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        Huacai Chen <chenhc@lemote.com>,
        Linux-MIPS <linux-mips@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Xuefeng Li <lixuefeng@loongson.cn>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Maciej W. Rozycki <macro@linux-mips.org> =E4=BA=8E2020=E5=B9=B43=E6=9C=8821=
=E6=97=A5=E5=91=A8=E5=85=AD =E4=B8=8A=E5=8D=885:24=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On Wed, 11 Mar 2020, Jiaxun Yang wrote:
>
> > __cpu_name[] will be displayed as "cpu model" in cpuinfo, however
> > in x86 world, the name line is started with "model name".
> > Most user applications like lscpu, hwinfo is following x86's rule, we d=
on't have superpower to move all of them.
> >
> > Also rename "cpu model" will break current ABI, so just create a new ar=
ray
> > for it would be a better option.
>
>  Well, /proc/cpuinfo is not an ABI, it's meant for human interaction (use
> `sysfs' for machine processing).

In fact there do be some code to use cpuinfo to detect cpu. Gcc is
even in this list.
https://codesearch.debian.net/search?q=3Dcpuinfo&literal=3D1

>
>  If tools want to use it anyway, then fine, but they need to adapt to the
> relative volatility of the free-form text interface, and also learn all
> the world is not x86 (just like all the MIPS world is not Loongson, so if
> you argue about adding effectively a duplicate field, then that would hav=
e
> to be applied across all the platforms).  IOW fix the tool and do not wor=
k
> its deficiencies around in the kernel just because it seems easier for yo=
u
> to do.
>
>  Here's how example /proc/cpuinfo looks like on RISC-V/Linux BTW:
>
> processor       : 0
> hart            : 1
> isa             : rv64imafdc
> mmu             : sv39
> uarch           : sifive,rocket0

If we create cpuinfo for a new architecture, we are freely do anything.
it is OK, as the newly write code can know about it, and there is no
old codes about it.

While if we have some modification to /proc/cpuinfo, of exists architecture=
s,
we must be very careful to keep compatible.

>
> [...]
>
> -- every Linux platform is different in this respect and tools have to
> live with that.

Yes, you are some right, the scripts/programs should be robust,
while they cannot forecast how the people change cpuinfo, if they are
freely....

>
>   Maciej


--=20
YunQiang Su