On Thu, 2005-12-22 at 10:34 -0500, Nicolas Pitre wrote:
> > 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.
>
> I'm with Christoph here. Please preserve my
> arch_mutex_fast_lock/arch_mutex_fast_unlock helpers. I did it that way
> because the most important thing they bring is flexibility where it is
> needed i.e. in architecture specific implementations. And done that way
> the architecture specific part is well abstracted with the minimum
> semantics allowing flexibility in the implementation.
>
> I insist on that because, even if ARM currently relies on the atomic
> swap behavior, on ARMv6 at least this can be improved even further, but
> a special implementation which is neither a fully qualified atomic
> decrement nor an atomic swap is needed. That's why I insist that you
> should keep my arch_mutex_fast_lock and friends (rename them if you
> wish) and remove __ARCH_WANT_XCHG_BASED_ATOMICS entirely.
>
Not sure how well this is accepted, but would it be acceptable to have
the mutex_lock and friends covered with the (weak) attribute?
ie.
void fastcall __sched __attribute__((weak)) mutex_lock(struct mutex *lock)
Then let the archs override them if they wish?
You would just need to make an extra slow path mutex visible to the archs.
-- Steve
-
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]
