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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/

[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]
  Powered by Linux