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.
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.
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?
Linus
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
