From owner-freebsd-arm@FreeBSD.ORG Sun Feb 21 22:27:03 2010 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CB81106566B; Sun, 21 Feb 2010 22:27:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A4F0E8FC1C; Sun, 21 Feb 2010 22:27:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o1LMP7HZ015742; Sun, 21 Feb 2010 15:25:07 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 21 Feb 2010 15:25:18 -0700 (MST) Message-Id: <20100221.152518.366306193186912981.imp@bsdimp.com> To: dougb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4B819F21.70907@FreeBSD.org> References: <20100221152824.GA58060@ci0.org> <4B819F21.70907@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, cognet@ci0.org Subject: Re: bind on arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 22:27:03 -0000 In message: <4B819F21.70907@FreeBSD.org> Doug Barton writes: : On 02/21/10 07:28, Olivier Houchard wrote: : > Hi Doug, : > : > I'd like to get the attached patch committed. It fixes the bind arm atomic : > stuff in -CURRENT and RELENG_8. Some times ago, the RAS address was changed, : > but it was hardcoded in the bind code and the change was never reflected. : > The patch uses a macro, so that even if it happens again it won't be a problem. : : First question (and I think the answer is yes, but I need to : double-check) is it the consensus of the ARM gurus that this is the : right solution? Second question, is this solution something that I can : send upstream, both in the sense that I have permission to do so, and : that it would be generally applicable to ARM on other OSs? The patch isn't quite right yet. First, there are no atomic operations on ARM ISA (prior to some of the really recent ones that we don't yet have support in our binutils for). In order to get atomic operations to work right, you have to have some variation of RAS (restartable atomic sequences). RAS is OS specific, as there's no standards what-so-ever for it. These sequences will generate atomic operations, but only if the OS restarts them if the OS preempts the thread. The code that's there now is very FreeBSD specific. In fact, it is explicitly tagged as such in the source. These patches don't change that. The code broke because we moved the RAS scratchpad area between revisions of FreeBSD. I think between 7 and 8, but I've not done the software archeology to be sure. At the very least, the code should be ifdef'd for the RAS address. Sadly, neither version exported the RAS constant in any useful way. While it is true it would be nicer of the application used FreeBSD atomic operations in the same way that all other applications do, this isn't easy in the case of Bind. Bind defined its own set of atomic operations, and all the other architectures conformed to bind's usage. On most other platforms, the atomic operations aren't OS dependent, just CPU dependent, so there wasn't a problem with Bind defining its own. After all, atomic operations haven't been standardized and there's a number of different ways to skin this cat. The fanciest way to cope would be to have a run-time check to see which address to use. This likely isn't worth the bother since the user base is still relatively small (and none of the other atomics do this). The next best approach would be to include and use the value defined there for ARM_RAS_START and ARM_RAS_END. Again, I've not double checked to make sure they are defined before, but I think they are (or at least if they aren't defined, we know to use the old value). Warner