Re: [patch 0/9] mutex subsystem, -V4

From: Christoph Hellwig
Date: Thu Dec 22 2005 - 06:53:03 EST


On Thu, Dec 22, 2005 at 12:41:47PM +0100, Ingo Molnar wrote:
> this is the -V4 of the mutex subsystem patch-queue. It consists of the
> following patches:
>
> add-atomic-xchg.patch
> add-atomic-call-func-i386.patch
> add-atomic-call-func-x86_64.patch
> add-atomic-call-wrappers-rest.patch
> mutex-core.patch
> mutex-switch-arm-to-xchg.patch
> mutex-debug.patch
> mutex-debug-more.patch
> xfs-mutex-namespace-collision-fix.patch
>
> the patches are against Linus' latest GIT tree, and they should work
> fine on every Linux architecture.
>
> Changes since -V3:
>
> - imlemented an atomic_xchg() based mutex implementation. It integrated
> pretty nicely into the generic code, and most of the code is still
> shared.
>
> - added __ARCH_WANT_XCHG_BASED_ATOMICS: if an architecture defines
> this then the generic mutex code will switch to the atomic_xchg()
> implementation.
>
> This should be conceptually equivalent to the variant Nicolas Pitre
> posted - Nicolas, could you check out this one? It's much easier to
> provide this in the generic implementation, and the code ends up
> looking cleaner.
>
> - eliminated ARCH_IMPLEMENTS_MUTEX_FASTPATH: there's no need for
> architectures to override the generic code anymore, with the
> introduction of __ARCH_WANT_XCHG_BASED_ATOMICS.
>
> - ARM: enable __ARCH_WANT_XCHG_BASED_ATOMICS.

I must admit I really really hat __ARCH_ stuff if we can avoid it.
An <asm/mutex.h> that usually includes two asm-generic variants is probably
a much better choice.

Actually just havign asm/mutex.h implement the faspath per-arch and get
rid of all the oddball atomic.h additions would be even better. While
this means we need per-arch code it also means the code is a lot easier
understandable, and we don't add odd public APIs.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/