From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753414AbdJTX0Y (ORCPT ); Fri, 20 Oct 2017 19:26:24 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:43535 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752699AbdJTX0W (ORCPT ); Fri, 20 Oct 2017 19:26:22 -0400 X-Google-Smtp-Source: ABhQp+Qv/GaR4IbKijQ7cPdtBmJUdff2P8mNZDdddNnsqlujjGEcTtKYR6WFQgaCfVK8+83P9bcEWg== Reply-To: ahs3@redhat.com Subject: Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable To: Mark Rutland Cc: Timur Tabi , "linux-arm-kernel@lists.infradead.org" , lkml , rruigrok@codeaurora.org, Jon Masters References: <20170926222324.17409-1-ahs3@redhat.com> <20170927103406.GC32150@leverpostej> <20171013142724.GA5893@leverpostej> <20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com> From: Al Stone Organization: Red Hat, Inc. Message-ID: <89947f32-0833-fb67-6bba-02bcac8ef01c@redhat.com> Date: Fri, 20 Oct 2017 17:26:19 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/20/2017 10:10 AM, Mark Rutland wrote: > 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... Harumph. This is the one thing I get asked for most often, however (second most is frequency). It turns out humans are not nearly as good at indexed lookups as computers, hence the requests. Whatever the root of the opposition is, it needs to get fixed. My fear is that if it doesn't get fixed in the firmware or the kernel, it will get fixed in some far messier, less controllable way somewhere else (more likely several somewhere elses) and just exacerbate the problem. >> 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. > -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@redhat.com ----------------------------------- From mboxrd@z Thu Jan 1 00:00:00 1970 From: ahs3@redhat.com (Al Stone) Date: Fri, 20 Oct 2017 17:26:19 -0600 Subject: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable In-Reply-To: <20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com> References: <20170926222324.17409-1-ahs3@redhat.com> <20170927103406.GC32150@leverpostej> <20171013142724.GA5893@leverpostej> <20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com> Message-ID: <89947f32-0833-fb67-6bba-02bcac8ef01c@redhat.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 10/20/2017 10:10 AM, Mark Rutland wrote: > 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... Harumph. This is the one thing I get asked for most often, however (second most is frequency). It turns out humans are not nearly as good at indexed lookups as computers, hence the requests. Whatever the root of the opposition is, it needs to get fixed. My fear is that if it doesn't get fixed in the firmware or the kernel, it will get fixed in some far messier, less controllable way somewhere else (more likely several somewhere elses) and just exacerbate the problem. >> 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. > -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3 at redhat.com -----------------------------------