Re: [PATCH] generalized spin_lock_bit

David S. Miller (davem@redhat.com)
Sat, 20 Jul 2002 18:31:33 -0700 (PDT)


From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: 21 Jul 2002 01:26:25 +0100

Secondly many platforms want to implement their locks in other ways.
Atomic bitops are an x86 luxury so your proposal simply generates
hideously inefficient code compared to arch specific sanity

For an asm-generic/bitlock.h implementation it is more than
fine. That way we get asm-i386/bitlock.h that does whatever
it wants to do and the rest of asm-*/bitlock.h includes
the generic version until the arch maintainer sees fit to
do otherwise.

See the difference between what we have here now? It means all ports
will at least sort-of work when the change gets installed. A lot of
testing gets lost because ports break on a daily basis due to changes
when done like this.

Look at the asm/rmap.h stuff, that was done right and platforms kept
at least compiling when that change went in.

I don't mind architecture breakage when truly necessary to change
stuff, but when it can be avoided reasonably it should.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/