Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment

[Linus Torvalds <torvalds@osdl.org>]

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 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/