From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752661AbdJTQK7 (ORCPT ); Fri, 20 Oct 2017 12:10:59 -0400 Received: from foss.arm.com ([217.140.101.70]:44768 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752081AbdJTQK5 (ORCPT ); Fri, 20 Oct 2017 12:10:57 -0400 Date: Fri, 20 Oct 2017 17:10:53 +0100 From: Mark Rutland To: Al Stone Cc: Timur Tabi , "linux-arm-kernel@lists.infradead.org" , lkml , rruigrok@codeaurora.org, Jon Masters Subject: Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable Message-ID: <20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com> References: <20170926222324.17409-1-ahs3@redhat.com> <20170927103406.GC32150@leverpostej> <20171013142724.GA5893@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.rutland@arm.com (Mark Rutland) Date: Fri, 20 Oct 2017 17:10:53 +0100 Subject: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable In-Reply-To: References: <20170926222324.17409-1-ahs3@redhat.com> <20170927103406.GC32150@leverpostej> <20171013142724.GA5893@leverpostej> Message-ID: <20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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.