Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3470205imm; Tue, 17 Jul 2018 05:30:29 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcyDz5o09DYKUeT7VJxQRbnVg3VLxgr89f6LbdXHakOA+0bFs2Msq8j9RasH0In/7BbO5Nh X-Received: by 2002:a63:7c18:: with SMTP id x24-v6mr1404920pgc.311.1531830629379; Tue, 17 Jul 2018 05:30:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531830629; cv=none; d=google.com; s=arc-20160816; b=Jws4ilvzzLq0VFQwkv9L5j/FyyWN6HpD0BaWNnEwF+WBw1ZFUfKWmzq9yAGTyOf126 SRrz8U5OpS8wdJcTbx4Ri7BlGaovPthxAuAdBUc9Bvew6B+ykLHpQ9hPNF/xQ8m675RN LkQZqQXw0m69QgBQDQz8WlQgBNgrU1qvaa0RIuh8gwzOGCHzvsfxa6Um1nxXljom+wCH jQxDcoIjuUxJZVLP6jlL357JAld2g5k7qCiEFOiTHhdpKr57ECu6Y4Z5ZLWkm8XNybhI ZMVp2Cy7UXFsWuZHyXISqxw5VDs0EpETBGOIMDCPFhR/kO/91IQWxur/7BzoaP2j4o0M ALMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=WFIQhRRJPQVEwn0W8wk/palFYsaKtR3C7kR9uNoL5Xw=; b=aT7lpcEYIqMlygBAP6hrwsNyTLCYd24xP2glh0PiJVcQ61g6cXruMqId8aerAlfVb1 s0NVA2acRN3f7QhQPqtxRTjWnTzN+zuZIJzcqC3jwZnGPY0bOOC6NP7kdVgaAZV658Hm Oty1nmefZ+kQzh3SuLe78HOlKRUf4fGQU3G3LTLHHgQQOpqSn3rSrTTuP3ND0rTxJpIL 6V0EjvHg+SXUh6y//+mHckuWyTZ8Ht4C09dpwGqXjOY+BacRZJV9MVbXtj2MKfQ1744k jH4DY/2wCsNj5Qbsp7wuqjSeJ0E0JGuKSQE0b2IOIeUARdOeJy7450sqUzuItCIckt4X cmiQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d20-v6si686888pgb.682.2018.07.17.05.30.14; Tue, 17 Jul 2018 05:30:29 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731526AbeGQNBi (ORCPT + 99 others); Tue, 17 Jul 2018 09:01:38 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:45842 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731242AbeGQNBi (ORCPT ); Tue, 17 Jul 2018 09:01:38 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1D61318A; Tue, 17 Jul 2018 05:29:12 -0700 (PDT) Received: from [10.1.211.22] (e110467-lin.cambridge.arm.com [10.1.211.22]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0C6743F5A0; Tue, 17 Jul 2018 05:29:10 -0700 (PDT) Subject: Re: [PATCH] arm64: cpuinfo: Include cleartext implementer and part strings To: Olof Johansson , Marc Zyngier Cc: Catalin Marinas , Will Deacon , Linux Kernel Mailing List , Linux ARM Mailing List References: <20180715035342.11371-1-olof@lixom.net> From: Robin Murphy Message-ID: Date: Tue, 17 Jul 2018 13:27:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/07/18 15:34, Olof Johansson wrote: [...] > There's also a growing expectation of the system to behave more like > x86, especially when it comes to trivial ways of detecting what kind > of machine you are running on. On x86 it's been trivial to look at > /proc/cpuinfo since it is provided by the platform there. Nobody wants > to change their implementation from having to read a file to exec a > program, dealing with errors, and parsing its output (sure, easier > from scripts, but more awkward from real source). The thing with the "be more like x86" argument is that it never actually stands up to scrutiny. What is proposed here (again) is for the kernel to decode the raw MIDR description of the *CPU core microarchitecture* to a human-readable string. What does the nearest Intel box say about its microarchitecture name? cpu family : 6 model : 79 OK, I had to go and look up that that apparently implies "Broadwell", so the x86 kernel is in fact no more helpful in that regard than arm64. Furthermore, telling the user that they have have 4 "Cortex-A53" cores vs. 4 "part: 0xd03" cores doesn't actually give them any more meaningful information about their *system*, because that example reflects about half the low-to-mid-range SoCs on the market today. What the "model name" on x86 describes is a specific processor SKU, of which Arm has no *architectural* equivalent, for reasons which should hopefully be obvious from the fundamental differences in the business models driving the respective architectures. And yet whenever /proc/cpuinfo/ comes up, nobody ever seems to ask for some kind of SoC identifier in there; it's always just decoding MIDR into a microarchitecture name, which implies that all these people want is to see a string for the sake of seeing a string, regardless of how meaningful it actually might be (and yes, I do realise that in *some* cases a CPU core is essentially unique to a particular SoC, but we have to look at the big picture here). In summary; when a small minority of users are complaining that oranges aren't apples, the sensible response is not to start debating whether to paint the oranges green or red. Robin.