From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6544 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.lib.musl.general,gmane.linux.ports.arm.kernel Subject: Re: ARM atomics overhaul for musl Date: Mon, 17 Nov 2014 09:38:46 -0800 Message-ID: References: <20141116055656.GA13940@brightrain.aerifal.cx> <20141116163355.GK4042@n2100.arm.linux.org.uk> <20141116165017.GT22465@brightrain.aerifal.cx> <20141116171055.GM4042@n2100.arm.linux.org.uk> <20141117135412.GC29595@e104818-lin.cambridge.arm.com> <20141117143905.GQ4042@n2100.arm.linux.org.uk> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1416245968 25193 80.91.229.3 (17 Nov 2014 17:39:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Nov 2014 17:39:28 +0000 (UTC) Cc: musl@lists.openwall.com, Catalin Marinas , Szabolcs Nagy , Kees Cook , Rich Felker , "linux-arm-kernel@lists.infradead.org" To: Russell King Original-X-From: musl-return-6557-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 17 18:39:21 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XqQGm-0003Q7-UL for gllmg-musl@m.gmane.org; Mon, 17 Nov 2014 18:39:21 +0100 Original-Received: (qmail 32133 invoked by uid 550); 17 Nov 2014 17:39:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32118 invoked from network); 17 Nov 2014 17:39:18 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b8x5BeuDGfy8bAbFu8QMgLuBI8ALGSIvnOIB6uakvVA=; b=F8LiWoYc4eysafPbNXv6u/7szHGa/NFV+l/5eN5o9s9ShNHWNLfLcUyXYkwu44ENuh yriF/BxEDqkaDaQHK5k1qc2duxiZjpUuEJnnsC7/eQlVTeTQhZq4GfFnsNuGon1l60cB OvXiTZhrAHX0jLOfsj4qaQobi5PEdxLJu0jw6usuhV17zmyOoDxoCDHKqi3JW46t2rF5 KA7XwMuKrfMyiJf6IAt8eMnnquc8AlCImZcFbGTVnjAJsrMicfxVwn/6i5WzAaIVhw46 MSpIIJNlEXGtCKT8Ee+gi4tLlssTmonKgN2jzCmLztCEXhxmsZpdSZj0Lhdx8pTKmkZ3 CnLQ== X-Gm-Message-State: ALoCoQlabz8thiNhIjXt4RcpCiQ2FjdS8q9MvQbImzcxUg/H0Ec8CP5P5AZJZyBLsPKIk0ILvqgB X-Received: by 10.112.133.138 with SMTP id pc10mr29625342lbb.48.1416245947245; Mon, 17 Nov 2014 09:39:07 -0800 (PST) In-Reply-To: <20141117143905.GQ4042@n2100.arm.linux.org.uk> Xref: news.gmane.org gmane.linux.lib.musl.general:6544 gmane.linux.ports.arm.kernel:372670 Archived-At: On Nov 17, 2014 6:39 AM, "Russell King - ARM Linux" wrote: > > On Mon, Nov 17, 2014 at 01:54:13PM +0000, Catalin Marinas wrote: > > On Sun, Nov 16, 2014 at 05:10:55PM +0000, Russell King - ARM Linux wrote: > > > which means that rather than encoding the > > > CPU architecture (like with every other Linux architecture), we have a > > > string which encodes the kernel architecture instead, which is absurd. > > > > Just like x86_64 vs i686? > > That is still valid, but let's wait and see what happens when a new > "version" of x86_64 comes along. > > However, the issue on x86 is far less of a problem: userspace (even > kernel space) does not have to play these games because the CPUs aren't > designed by people intent on removing old instructions from the > instruction set, thereby stopping existing binaries working without > kernel emulation of the missing instructions. > > > > Obviously, the plan for ARM64 is that there will never be an ARMv9 > > > architecture, and ARMv8 is the perfect architecture for the future. :p > > > > If you haven't noticed, the distinction between ARMv6 and ARMv7 has been > > blurred enough (guess why cpu_architecture() reports ARMv7 for > > ARM11MPCore). ARM is trying to move away from architecture version > > numbers, which are rather useful for marketing, to proper feature > > detection based on CPUID. Whether there is an ARMv9 or not, it's > > irrelevant to what Linux should do (i.e. use CPUID rather than guess > > features based on architecture version numbers). > > That may be what is desired, but unfortunately we have no way to export > all the intricate feature registers to userspace. No, elf hwcaps don't > support it, there's only 64 bits split between two words there, and > there are many more than just 64 bits of feature registers. That's a ridiculous argument. Linux can freely add bits. You could add AT_ARM_FEATURES that points to a length followed by the indicated number of words, or you could just keep adding new HWCAP fields as needed. This is expandable forever. As an x86 person and a complete ARM outsider, this situation is totally nuts. There is no good reason *not* to have feature bits, and even in x86 land, relying on the architecture version is dangerous. (Intel seems to be reinstating version 5 right now with Quark, and even that is having minor issues since it's not really quite a version 5 chip.) > > Given that even cocked these up (just as what happened with the cache > type register) decoding of the feature type registers depends on the > underlying CPU architecture. > > So, even _if_ we exported the feature registers to userspace, you still > need to know the CPU architecture to decode them properly, so you still > need to parse the AT_PLATFORM string to get that information. > There's no need to expose the hardware feature registers as is. Define your own sensible feature bits just for Linux. Yes, libc implementations will need a fallback for old kernels, but at least the set of legacy configurations that need to be supported that way will stop increasing at some point. --Andy > > > So, a reasonable parsing of this would be: > > > > > > const char *ptr; > > > int architecture; > > > > > > ptr = (const char *)(uintptr_t)getauxval(AT_PLATFORM); > > > assert(ptr); > > > > > > if (!strncmp(ptr, "aarch64", 7)) > > > architecture = 8; > > > else > > > assert(sscanf(ptr, "v%d", &architecture) == 1); > > > > Oh, have you even bothered trying 32-bit (compat) getauxval(AT_PLATFORM) > > on an aarch64 kernel? It reports "v8l", so please don't confuse others. > > Right, I see that now - I'm not knowledgable of the compat code, because > ARM32 has nothing to do with it, and I missed COMPAT_ELF_PLATFORM. > > As for "bothered trying" - tell me how I could possibly try that. You > know full well that I have /no/ 64-bit hardware, and you also know that > I have *nothing* capable of running, let alone building a 64-bit ARM > kernel. > > Please, next time you decide to make accusations, bear that in mind - my > "guesses" as to what ARM64 does are based upon reading your code, > sometimes for the first time, and not through any kind of experience of > actually running the damned stuff. > > Now, think about what /you/ have said. Think about your assertion about > that "v8l" string. How does the code react to that? Oh my, it sets > "architecture" to 8 ! Oh lookie, it's the right value. Oh look, the > code works correctly. > > So, counter to your crap about me confusing others, maybe you should > make that same accusation of yourself! > > Maybe ARM and yourself should have tried to be more inclusive with ARMv8 > in general, rather than trying to push me away with accusations and the > like (like you're doing right now) every time I say something about it. > > -- > FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up > according to speedtest.net.