linux-kernel - Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 20 Oct 2017 17:10:53 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Al Stone <ahs3@...hat.com>
Cc:     Timur Tabi <timur@...eaurora.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        lkml <linux-kernel@...r.kernel.org>, rruigrok@...eaurora.org,
        Jon Masters <jcm@...hat.com>
Subject: Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more
 human-readable

Hi Al,

On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote:
> On 10/13/2017 08:27 AM, Mark Rutland wrote:
> > I certainly agree that exposing the information that we have is useful,
> > as I have stated several times. I'm not NAKing exposing this information
> > elsewhere.
> > 
> > If you want a consistent cross-architecture interface for this
> > information, then you need to propose a new one. That was we can
> > actually solve the underlying issues, for all architectures, without
> > breaking ABI.
> > 
> > I would be *very* interested in such an interface, and would be more
> > than happy to help.
> 
> I'm playing with some patches that do very similar things in sysfs, vs
> proc.  Is that better :)?

Exposing data under sysfs is certainly better, yes. :)

> Obviously, you'll have to see the patches to
> properly answer that, but what I'm playing with at present is placing
> this info in new entries in /sys/devices/cpu and/or /sys/devices/system,
> and generating some of the content based on what's already in header files
> (e.g., in cputype.h). 

My opposition to MIDR -> string mapping applies regardless of
location...

> The idea of course is to keep this new info from touching any existing
> info so we don't break compatibility -- does that feel like a better
> direction, at least?

... but otherwise this sounds good to me!

Thanks,
Mark.