On Thu, 22 Dec 2005, Ingo Molnar wrote:
> The discussion was not about ARMv5 at all. The discussion was about the
> claim that 'ARMv6 is somehow magical that it needs its own stuff'. No it
> isnt magical, it's a sane CPU that can implement a sane
> atomic_dec_return(), or even better, a sane atomic_*_call_if_*()
> primitive. Or whatever primitive we end up having - i dont mind if it's
> called __mutex_whatever, as long as it has a _well defined_ meaning.
I'd like to point out that, while atomic_dec_call_if_* is really nice on
i386, it is probably only good for i386 since no other architecture
will be able to provide a better implementation than what can be done
with atomic_dec_return() anyway. Yet that IMHO overloaded
atomic_dec_call_if_* stuff appears in core code.
But like for i386, those other architectures might be able to do some
other tricks to achieve the same needed semantics. My ARMv6 is one of
them (and no it doesn't strictly follows the semantics of
atomic_dec_call_if_*). Are you willing to add more #if
defined(CONFIG_MUTEX_FOO_ALGO) in the core code as time goes by? I hope
not.
> what i _DONT_ want is some over-opaque per-arch thing that will again
> escallate into the same situation as semaphores: 23 different
> implementations nobody is able to change at once, nobody is able to add
> features or debugging to, and by today there's probably is no single
> person on this planet who knows all 23 of them to begin with.
I agree completely with you. But what I don't want is core code
needlessly restricting architecture specific implementation for short
and well defined fast paths. Maybe that's where we must agree upon: a
well defined fast path helper for mutexes?
Nicolas
-
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]
