From mboxrd@z Thu Jan 1 00:00:00 1970 From: Willy Tarreau Subject: Re: Linux 2.4.26-rc1 (cmpxchg vs 80386 build) Date: Mon, 29 Mar 2004 21:57:36 +0200 Sender: linux-kernel-owner@vger.kernel.org Message-ID: <20040329195736.GC18399@alpha.home.local> References: <1080535754.16221.188.camel@dhcppc4> <20040329052238.GD1276@alpha.home.local> <200403290901.47695.vda@port.imtp.ilyichevsk.odessa.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <200403290901.47695.vda@port.imtp.ilyichevsk.odessa.ua> To: Denis Vlasenko Cc: Len Brown , Arkadiusz Miskiewicz , Marcelo Tosatti , linux-kernel@vger.kernel.org, ACPI Developers List-Id: linux-acpi@vger.kernel.org On Mon, Mar 29, 2004 at 09:01:47AM +0200, Denis Vlasenko wrote: > > > 4. re-implement locks for the 80386 case. > > > > I like this one, but a simpler way : don't support SMP in this case, so > > that we won't have to play with locks. This would lead to something like > > this : > > Yes, SMP makes sense only on 486+ Indeed, Andi made a good point : some people compile for 386 as a generic target which can potentially run on more recent hardware with ACPI support. May be we should consider this behaviour broken anyway, since there are other features that will never be available, such as TSC. So why not simply disable ACPI for 386 ? > Inline func please. We definitely don't want to evaluate > lock and old expressions several times. That's right. But I'm too lazy this evening for something which has too few chances of being the definitive solution :-) Cheers, willy