Christoph Lameter wrote:
--- linux-2.6.orig/include/asm-ia64/bitops.h 2007-10-19 04:05:38.000000000
-0700
+++ linux-2.6/include/asm-ia64/bitops.h 2007-10-19 10:50:34.000000000 -0700
...
/**
+ * __clear_bit_unlock - Non-atomically clear a bit with release
+ */
+static __inline__ void
+__clear_bit_unlock (int nr, volatile void *addr)
+{
+ barrier();
+ __clear_bit(nr, addr);
+}
+
+/**
Well, the "old" __clear_bit() went like this:
__clear_bit (int nr, volatile void *addr)
{
*((__u32 *) addr + (nr >> 5)) &= ~(1 << (nr & 31));
}
(I really do not see why "addr" is a pointer to a volatile stuff.
If it really can change independently from the current thread of
control, then a non atomic operation is not much useful.
Luckily :-) "addr" is casted into a pointer to a non volatile stuff.)
It has been changed into:
__clear_bit (int nr, volatile void *addr)
{
volatile __u32 *p = (__u32 *) addr + (nr >> 5);
__u32 m = 1 << (nr & 31);
*p &= ~m;
}
I guess because of __clear_bit_unlock() needs only.
__set_bit() still keeps its ".rel" / ".acq" free store / load instruction.
__set_bit (int nr, volatile void *addr)
{
*((__u32 *) addr + (nr >> 5)) |= (1 << (nr & 31));
}
Note that most of the __clear_bit() / __set_bit() usage are some bit map
or indicator manipulations. They do not need any ".rel" / ".acq"
semantics.
Let's put back the old ".rel" / ".acq" free __clear_bit() and
let's use specific variant of ...clear_bit() where ".rel" semantics
is requred.
Let's avoid adding ".acq" semantics to ...clear_bit() where is is not
required.
Zoltan
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
