Messages in this thread |  | | | Subject | Re: [patch 0/9] mutex subsystem, -V4 | | From | Steven Rostedt <> | | Date | Thu, 22 Dec 2005 12:33:00 -0500 |
| |
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 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/
|  |