Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765422AbZAOOQQ (ORCPT ); Thu, 15 Jan 2009 09:16:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756346AbZAOOP7 (ORCPT ); Thu, 15 Jan 2009 09:15:59 -0500 Received: from ftp.linux-mips.org ([213.58.128.207]:52847 "EHLO ftp.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755084AbZAOOP7 (ORCPT ); Thu, 15 Jan 2009 09:15:59 -0500 Date: Thu, 15 Jan 2009 14:15:56 +0000 (GMT) From: "Maciej W. Rozycki" To: Alan Cox cc: Jan-Benedict Glaw , Ingo Molnar , Peter Zijlstra , Jiri Kosina , Adam Osuchowski , linux-kernel@vger.kernel.org, Nick Piggin , Thomas Gleixner , "H. Peter Anvin" Subject: Re: Is 386 processor still supported? In-Reply-To: <20090115133252.28c36adb@lxorguk.ukuu.org.uk> Message-ID: References: <20090108120338.6b8b4567@zonk.pl> <1231424025.11687.447.camel@twins> <1231424833.11687.452.camel@twins> <20090108150448.2393aeb0@lxorguk.ukuu.org.uk> <20090108151046.GK18120@elte.hu> <20090115123614.GR11087@lug-owl.de> <20090115133252.28c36adb@lxorguk.ukuu.org.uk> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1201 Lines: 26 On Thu, 15 Jan 2009, Alan Cox wrote: > > UP emulation of CMPXCHG and XADD for userland should be rather trivial, > > so why not include it like with LL/SC for MIPS? > > Why not just ship an additional libc with the right options ? Does not work for MIPS as glibc has no equivalent code for pre-LL/SC CPUs and LL/SC is always used. For the i386 the situation seems worse yet as for pre-i486 CPUs a generic C implementation of compare-and-exchange is used guaranteeing silent thread unsafety. :( IMO, a kernel emulation of CMPXCHG and XADD (both are used by sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix, guaranteeing UP atomicity would be a cheap way to provide long-term i386 userland support with little burden for both Linux and respective user software maintainers. Certainly it adds some bloat to the kernel, but I think it is not an option that should be outright dismissed without consideration. Maciej -- 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/