RE: [PATCH] MIPS: kernel: proc: Remove spurious white space in cpuinfo

[Miodrag Dinic]

Hi,

the issue was found on Android using VTS, where its cpuinfo parser stumbled upon an extra space while trying to extract information about FPU.
By comparing with ARM and Intel it seemed that only MIPS had this quirk in the cpuinfo format, so we submitted this change to make it conform
to the format used by other architectures.  

However I agree that this is pretty sensitive code to userspace and it is better to leave it as is.
@Macijej, David, thank you for pointing out the risks and explanation of the origin of this extra space in the cpuinfo format.

Please ignore this change.

Kind regards,
Miodrag
________________________________________
From: David Daney [ddaney@xxxxxxxxxxxxxxxxxx]
Sent: Saturday, October 21, 2017 1:56 AM
To: Maciej Rozycki; Aleksandar Markovic
Cc: linux-mips@xxxxxxxxxxxxxx; Dragan Cecavac; Aleksandar Markovic; Douglas Leung; Goran Ferenc; James Hogan; James Hogan; linux-kernel@xxxxxxxxxxxxxxx; Maciej W. Rozycki; Miodrag Dinic; Paul Burton; Paul Burton; Petar Jovanovic; Raghu Gandham; Ralf Baechle
Subject: Re: [PATCH] MIPS: kernel: proc: Remove spurious white space in cpuinfo

On 10/20/2017 01:47 PM, Maciej W. Rozycki wrote:
> On Fri, 20 Oct 2017, Aleksandar Markovic wrote:
>
>> Remove unnecessary space from FPU info segment of /proc/cpuinfo.
>
>   NAK.  As I recall back in Nov 2001 I placed the extra space there to
> visually separate the CPU part from the FPU part, e.g.:
>
> cpu model             : R3000A V3.0  FPU V4.0
> cpu model             : SiByte SB1 V0.2  FPU V0.2
>
> etc.  And the motivation behind it still stands.  Please remember that
> /proc/cpuinfo is there for live humans to parse and grouping all these
> pieces together would make it harder.  Which means your change adds no
> value I'm afraid.

I think it is even riskier than that.  This is part of the
kernel-userspace ABI, many programs parse this file, any gratuitous
changes risk breaking something.

I don't really have an opinion about the various *printf functions being
used, but think the resultant change in what is visible to userspace
should not be done.

>
>   NB regrettably back in those days much of the patch traffic happened off
> any mailing list, however I have quickly tracked down my archival copy of
> the original submission of the change introducing this piece of code and
> I'll be happy to share it with anyone upon request.
>
>    Maciej
>