Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761153AbWLHToM (ORCPT ); Fri, 8 Dec 2006 14:44:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1426164AbWLHToM (ORCPT ); Fri, 8 Dec 2006 14:44:12 -0500 Received: from caramon.arm.linux.org.uk ([217.147.92.249]:4573 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761153AbWLHToL (ORCPT ); Fri, 8 Dec 2006 14:44:11 -0500 Date: Fri, 8 Dec 2006 19:43:57 +0000 From: Russell King To: Linus Torvalds Cc: Christoph Lameter , David Howells , Nick Piggin , akpm@osdl.org, linux-arm-kernel@lists.arm.linux.org.uk, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Subject: Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it Message-ID: <20061208194357.GJ31068@flint.arm.linux.org.uk> Mail-Followup-To: Linus Torvalds , Christoph Lameter , David Howells , Nick Piggin , akpm@osdl.org, linux-arm-kernel@lists.arm.linux.org.uk, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org References: <20061207150303.GB1255@flint.arm.linux.org.uk> <4578BD7C.4050703@yahoo.com.au> <20061208085634.GA25751@flint.arm.linux.org.uk> <4595.1165597017@redhat.com> <20061208171816.GG31068@flint.arm.linux.org.uk> <20061208193116.GI31068@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1250 Lines: 31 On Fri, Dec 08, 2006 at 11:37:45AM -0800, Linus Torvalds wrote: > > > On Fri, 8 Dec 2006, Russell King wrote: > > > > I utterly disagree. I could code atomic_add() as: > > Sure. And Alpha could do that too. If you write the C code a specific way, > you can make it work. That does NOT mean that you can expose it widely as > a portable interface - it's still just a very _nonportable_ interface that > you use internally within one architecture to implement other interfaces. However, nothing stops you wrapping the non-portable nature of ll/sc up into the store part though. If you can efficiently implement cmpxchg inside an ll/sc based portable interface (yes you can) and you can implement problematical ll/sc structures inside a cmpxchg() interface, you can do it either way around. Only one way doesn't penalise broken ll/sc based implementations though. That is the essence of my argument. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - 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/