From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6517 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.linux.ports.arm.kernel Subject: Re: ARM atomics overhaul for musl Date: Sun, 16 Nov 2014 13:56:22 -0500 Message-ID: <20141116185622.GV22465@brightrain.aerifal.cx> 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> 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 1416164214 30483 80.91.229.3 (16 Nov 2014 18:56:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Nov 2014 18:56:54 +0000 (UTC) Cc: Russell King - ARM Linux , musl@lists.openwall.com, Szabolcs Nagy , Kees Cook , "linux-arm-kernel@lists.infradead.org" To: Andy Lutomirski Original-X-From: musl-return-6530-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 16 19:56:47 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 1Xq50A-0006ja-MD for gllmg-musl@m.gmane.org; Sun, 16 Nov 2014 19:56:46 +0100 Original-Received: (qmail 30390 invoked by uid 550); 16 Nov 2014 18:56:45 -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 30378 invoked from network); 16 Nov 2014 18:56:44 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6517 gmane.linux.ports.arm.kernel:372252 Archived-At: On Sun, Nov 16, 2014 at 10:27:04AM -0800, Andy Lutomirski wrote: > Would it make sense for arm and arm64 to add bits for these features > to AT_HWCAP, along with an extra bit indicating that the kernel > provides these bits? Sadly since it wasn't available there from the beginning, I don't think there would be a lot of benefit in adding it now, but it wouldn't hurt. It might be useful if there's a risk that the existing methods will break in the future; adding it now would ensure that there are only a known finite set of kernels for which the old hackish string methods need to be used, so that there's no concern about their compatibility with future kernels/models. Rich