Date: Sun, 21 Feb 2010 15:25:18 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: dougb@FreeBSD.org Cc: freebsd-arm@FreeBSD.org, cognet@ci0.org Subject: Re: bind on arm Message-ID: <20100221.152518.366306193186912981.imp@bsdimp.com> In-Reply-To: <4B819F21.70907@FreeBSD.org> References: <20100221152824.GA58060@ci0.org> <4B819F21.70907@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <4B819F21.70907@FreeBSD.org>
Doug Barton <dougb@FreeBSD.org> 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 <machine/sysarch.h>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100221.152518.366306193186912981.imp>