Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030230AbVLVRdM (ORCPT ); Thu, 22 Dec 2005 12:33:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030232AbVLVRdM (ORCPT ); Thu, 22 Dec 2005 12:33:12 -0500 Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]:40346 "EHLO ms-smtp-01.nyroc.rr.com") by vger.kernel.org with ESMTP id S1030230AbVLVRdL (ORCPT ); Thu, 22 Dec 2005 12:33:11 -0500 Subject: Re: [patch 0/9] mutex subsystem, -V4 From: Steven Rostedt To: Nicolas Pitre Cc: Ingo Molnar , Christoph Hellwig , lkml , Linus Torvalds , Andrew Morton , Arjan van de Ven , Jes Sorensen , Zwane Mwaikambo , Oleg Nesterov , David Howells , Alan Cox , Benjamin LaHaise , Andi Kleen , Russell King In-Reply-To: References: <20051222114147.GA18878@elte.hu> <20051222115329.GA30964@infradead.org> Content-Type: text/plain Date: Thu, 22 Dec 2005 12:33:00 -0500 Message-Id: <1135272780.12761.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1762 Lines: 41 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/