Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment | Date | Tue, 12 Dec 2006 23:17:22 +0000 |
| |
Russell King <rmk+lkml@arm.linux.org.uk> 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 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/
| |