From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932223AbbIBUL5 (ORCPT ); Wed, 2 Sep 2015 16:11:57 -0400 Received: from www.linutronix.de ([62.245.132.108]:59208 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932102AbbIBULv (ORCPT ); Wed, 2 Sep 2015 16:11:51 -0400 Date: Wed, 2 Sep 2015 22:11:12 +0200 (CEST) From: Thomas Gleixner To: "Pinski, Andrew" cc: Catalin Marinas , Siarhei Siamashka , Mark Rutland , "steve.capper@linaro.org" , Suzuki Poulose , "linux-kernel@vger.kernel.org" , Andrew Pinski , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector In-Reply-To: Message-ID: References: <1440873982-44062-1-git-send-email-apinski@cavium.com> <20150901163304.GC16430@leverpostej> <4C8DD5E0-E1EA-40C6-B947-72189241023C@caviumnetworks.com> <20150901173043.GE16430@leverpostej> <9AA83792-C973-4642-88BA-3C59F23EB048@gmail.com> <20150901221254.5e08ab6e@i7> <8C837F8F-050A-45DD-882B-02E107EFD663@caviumnetworks.com> <20150902165752.782e75be@i7> ,<20150902171157.GC25614@e104818-lin.cambridge.arm.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001,URIBL_BLOCKED=0.001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2 Sep 2015, Pinski, Andrew wrote: > > On Sep 3, 2015, at 1:12 AM, Catalin Marinas wrote: > >> On Wed, Sep 02, 2015 at 10:52:05PM +0800, Andrew Pinski wrote: > >> That is not a bad idea. Put this array in the data section of the > >> VDSO too. It should be small enough though on systems with 96 or more > >> cores (dual socket ThunderX has 96 cores total), it is slightly > >> getting big. > >> The struct would be something like: > >> struct > >> { > >> int32 numcores; > >> int32 midr[]; > >> }; > > > > First of all, I'm against hard-coding (VDSO) data as ABI. So far we used > > VDSO to override some weak glibc functions but the VDSO-specific data is > > parsed by the VDSO function implementation and not directly by glibc (or > > user space). I prefer helper functions that read the VDSO-internal data > > structures. > > You don't like the idea of a fixed structure ABI that resides inside > vdso data? Having a fixed struct ABI should be ok. The location > inside the data part was going to be passed via an aux vector entry. > Userland does even need to know it is really located in the vdso at > all. It just happens to reside in there. The data structure would be > well defined for the aux vector. Restrict the VDSO ABI to well defined single purpose functions. It's way harder to define data struct ABIs right from the beginning. Thanks, tglx