Linus Torvalds wrote:
On Tue, 12 Dec 2006, Russell King 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?
Well, others have answered that ("wrong sizes"), but I'm wavering on using
atomic_long_t. I have to admit that I'd rather not add a new accessor
function, when it _should_ be easier to use the current ones.
I agree.
That does depend on every arch maintainer saying they're ok with mixing
bitops and "atomic*_t"s. It would also require us to at least add some
_minimal_ function to get at the actual value, and turn the pointer into a
"unsigned long *" for the bitop functions.
I would _hope_ that people hopefully already use the same locking for
atomic_t and for bitops, and that arch maintainers could just say "sure,
that works for me". Obvously, anybody with LL/SC or otherwise just
basically atomic bitops (which covers a fair part of the spectrum) should
be ok, but sparc and the usual cast of suspects would have to say that
it's ok.
parisc seems to, but sparc uses its own open coded spinlock for bitops, and
the array of regular spinlocks for atomic ops. OTOH, consolidating them
might give more scalable code *and* a smaller cacheline footprint?
Should we also just make the rule be that the architecture _must_ allow
the silly
(atomic_long_t *) -> (unsigned long *)
casting (so that we can make _one_ generic inline function that takes an
atomic_long_t and returns the same pointer as an "unsigned long *" to make
bitop functions happy), or would this have to be another arch-specific
function?
Comments?
AFAIK no architecture does anything special, so maybe a generic converter
would be best, until one comes along that does. (the only thing of note
really is that half of the atomics use volatile types and half don't, is
that a problem?).
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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/
