Russell King <[EMAIL PROTECTED]> wrote: > This seems to be a very silly question (and I'm bound to be utterly > wrong as proven in my last round) but why are we implementing a new > set of atomic primitives which effectively do the same thing as our > existing set? > > Why can't we just use atomic_t for this?
atomic_t is the wrong thing as it's basically an int, not an unsigned long. atomic64_t/atomic_long_t is also probably the wrong thing to use as it's a signed long (and the long is also volatile on some platforms - x86_64 for example). Bitops operate on unsigned long. But the most important point is that assign_bits() has to take the same pointer type as test_bit(), set_bit(), test_and_set_bit(), etc., and none of those operate on an atomic*_t. We could change that, of course, but I don't fancy tackling the task just at the moment. It oughtn't to be a difficult change, but there are a lot of flags words in the kernel. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
