From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6545 Path: news.gmane.org!not-for-mail From: Catalin Marinas Newsgroups: gmane.linux.lib.musl.general,gmane.linux.ports.arm.kernel Subject: Re: ARM atomics overhaul for musl Date: Mon, 17 Nov 2014 17:48:03 +0000 Message-ID: <20141117174803.GH29595@e104818-lin.cambridge.arm.com> 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> <20141117152624.GF20652@localhost> <20141117154739.GT4042@n2100.arm.linux.org.uk> <20141117161941.GG29595@e104818-lin.cambridge.arm.com> <20141117165334.GW4042@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=us-ascii X-Trace: ger.gmane.org 1416246521 3020 80.91.229.3 (17 Nov 2014 17:48:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Nov 2014 17:48:41 +0000 (UTC) Cc: Rich Felker , Szabolcs Nagy , "musl@lists.openwall.com" , Kees Cook , "linux-arm-kernel@lists.infradead.org" , Andy Lutomirski To: Russell King - ARM Linux Original-X-From: musl-return-6558-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 17 18:48:32 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 1XqQPf-00083b-1H for gllmg-musl@m.gmane.org; Mon, 17 Nov 2014 18:48:31 +0100 Original-Received: (qmail 8024 invoked by uid 550); 17 Nov 2014 17:48:30 -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 8004 invoked from network); 17 Nov 2014 17:48:29 -0000 Content-Disposition: inline In-Reply-To: <20141117165334.GW4042@n2100.arm.linux.org.uk> Thread-Topic: ARM atomics overhaul for musl Accept-Language: en-GB, en-US Content-Language: en-US acceptlanguage: en-GB, en-US User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:6545 gmane.linux.ports.arm.kernel:372676 Archived-At: On Mon, Nov 17, 2014 at 04:53:34PM +0000, Russell King - ARM Linux wrote: > On Mon, Nov 17, 2014 at 04:19:42PM +0000, Catalin Marinas wrote: > > Similarly for AArch32, I think we should switch our focus from version > > numbers (well, only from v7/v8) to features (exposed by the hardware to > > the kernel via CPUID). An example is how we got LPAE on ARMv7 without a > > change in the architecture version number. We even expose this to user > > space via hwcap because that's how we know we have atomic LDRD/STRD. > > For this case, I disagree. There is no value (in fact, there is lots of > harm) to adding a hwcap bit for this. > > If we added such a hwcap bit, it would mean that userspace would have > to implement the check that I suggested, plus a check for the hwcap bit, > plus maybe a kernel version check to decide which test to use. [...] > So, I really don't see the point in exposing the presence of DMB via > a hwcap bit - if we wanted to do that, it's something that we should > have done at the very start, but we didn't. Now, it's pointless to > do so. I agree with you on a HWCAP_DMB bit, it's too late now and code should rely on the architecture version instead. But my point is about new features that will appear (or already did) in the current or next architecture versions (e.g. ARMv8). So far we seem to have avoided adding HWCAP bits for new features that were mandated by certain architecture versions, probably under the assumption that software would check the architecture version number. For example, on ARMv8, do you want to add a HWCAP_LDACQ (for acquire/release semantics) or we tell user space to check for "v8l" instead? There are additional hints available for AArch32 DMB and DSB (ISHLD, OSHLD, NSHLD, LD), there are LDREX/STREX with acquire/release semantics, a new SEVL instruction. User space needs to know about these not only from a backwards compatibility perspective (I don't expect DMB to ever go away) but from a future optimisation one. If you are worried about the risk of running out of HWCAP bits (we still have I think 32 left, we could also introduce elf_hwcap3), what about, for new features, adding a HWCAP_CPUID (only when the extended CPUID is present) and, when enabled, allow user space to probe CPUID registers via an ARM-specific syscall or undef hooks? These would filtered by the kernel, it doesn't need to always present the real register content, especially on heterogeneous systems. -- Catalin