Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932271AbWHCFdM (ORCPT ); Thu, 3 Aug 2006 01:33:12 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932270AbWHCFdM (ORCPT ); Thu, 3 Aug 2006 01:33:12 -0400 Received: from omx1-ext.sgi.com ([192.48.179.11]:35993 "EHLO omx1.americas.sgi.com") by vger.kernel.org with ESMTP id S932271AbWHCFdL (ORCPT ); Thu, 3 Aug 2006 01:33:11 -0400 Date: Wed, 2 Aug 2006 22:32:56 -0700 (PDT) From: Christoph Lameter To: Andi Kleen cc: virtualization@lists.osdl.org, Jeremy Fitzhardinge , akpm@osdl.org, xen-devel@lists.xensource.com, Chris Wright , Ian Pratt , linux-kernel@vger.kernel.org Subject: Re: [patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor. In-Reply-To: <200608030725.13713.ak@suse.de> Message-ID: References: <20060803002510.634721860@xensource.com> <200608030649.11452.ak@suse.de> <200608030725.13713.ak@suse.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1962 Lines: 45 On Thu, 3 Aug 2006, Andi Kleen wrote: > > As far as I can tell from this conversation there are special "Xen" > > drivers that need this not the rest of the system. > > Yes, but in general when a driver that runs on multiple architectures > (including IA64 btw) needs something architecture specific we usually > add it to asm, not add ifdefs. I still wonder why you are so focused on ifdefs. Why would we need those? > > What possible use could there be to someone else? > > e.g. for other hypervisors or possibly for special hardware access > (e.g. I could imagine it being used for some kind of cluster interconnect) > I remember Alan was using a similar hack in his EDAC drivers because > it was the only way to clear ECC errors. Maybe the best thing would be to have proper atomic ops in UP mode on i386? The current way of just dropping the lock bit is the source of the troubles. > > The "atomic" ops lock/unlock crap exists only for i386 as far as I can > > tell. As you said most architectures either always use atomic ops or > > never. The lock/unlock atomic ops are i386 specific material that > > better stay contained. Its arch specific and not generic. > > Well we have our share of weird hacks for IA64 too in generic code. But we all try to contain them. Here we have i386 hacks multiplying all over the system. > Just adding a single line #include for a wrapper asm-generic surely isn't > a undue burden for the other architectures, and it will save some > mess in the Xen drivers. Just adding a single line #include to drivers that need this functionality is not an undue burden for the drivers that support Xen. They have to use special _xxx bitops anyways. - 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/