From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azla6-00074q-Ue for qemu-devel@nongnu.org; Mon, 09 May 2016 09:50:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1azla5-0000a2-6g for qemu-devel@nongnu.org; Mon, 09 May 2016 09:50:42 -0400 Date: Mon, 9 May 2016 13:44:11 +0000 From: Catalin Marinas Message-ID: <20160509134410.GA2504@localhost.localdomain> References: <570B7048.5010501@arm.com> <570E1866.9010201@arm.com> <57306DA7.4010002@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC PATCH v2 2/3] utils: Add cpuinfo helper to fetch /proc/cpuinfo List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Suzuki K Poulose , Vijay Kilari , Will Deacon , Vijaya Kumar K , qemu-arm , Paolo Bonzini , QEMU Developers , Prasun Kapoor , suresh knv , Vijaya Kumar K , Suresh On Mon, May 09, 2016 at 12:21:08PM +0100, Peter Maydell wrote: > On 9 May 2016 at 11:59, Suzuki K Poulose wrote: > > Well, we have been waiting for a use case, like this, before we merge > > the series. > > This isn't a great strategy for moving people away from things > you'd like them to avoid like parsing /proc/cpuinfo, because typically > userspace app writers are not very interested in coding to facilities > which don't exist yet, and will prefer to make do with what's actually > present in the kernel today... You need to provide the improved API, > and then it needs to get out into kernel versions in distros and > otherwise, and only then are you likely to get app developers who > will start to say "this is useful". The problem is that the way kernel people think the API may be improved does not always match the use-cases required by app writers. One example here is exposing MIDR via MRS emulation, we know there are problems with big.LITTLE and the only clear answer I got so far is that we ignore such configurations. We don't even have a way to tell user space that this is a heterogeneous CPU configuration, unless we add another HWCAP bit specifically for this (or the opposite: HWCAP_HOMOGENEOUS_CPUS). That said, I'm perfectly fine with exposing: /sys/devices/system/cpu/cpu$ID/identification/ \- midr \- revidr I had the wrong impression that we already merged this part but Suzuki just pointed out to me that it's not. I think our 4.7-rc1 tree is pretty much frozen to new features now, though the sysfs patch is relatively small (I'll let Will comment): https://patches.linaro.org/patch/54502/ The MRS emulation, we should restart the discussion around big.LITTLE implications and make a decision one way or another by the 4.8 merging window. -- Catalin