Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261947AbUCaNHv (ORCPT ); Wed, 31 Mar 2004 08:07:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261952AbUCaNHv (ORCPT ); Wed, 31 Mar 2004 08:07:51 -0500 Received: from mail.tmr.com ([216.238.38.203]:4103 "EHLO gatekeeper.tmr.com") by vger.kernel.org with ESMTP id S261947AbUCaNHu (ORCPT ); Wed, 31 Mar 2004 08:07:50 -0500 Date: Wed, 31 Mar 2004 08:04:10 -0500 (EST) From: Bill Davidsen To: "Maciej W. Rozycki" cc: Len Brown , Chris Friesen , Willy Tarreau , "Richard B. Johnson" , Alan Cox , Arkadiusz Miskiewicz , Marcelo Tosatti , Linux Kernel Mailing List , ACPI Developers Subject: Re: [ACPI] Re: Linux 2.4.26-rc1 (cmpxchg vs 80386 build) In-Reply-To: Message-ID: 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: 1265 Lines: 30 On Wed, 31 Mar 2004, Maciej W. Rozycki wrote: > On Tue, 30 Mar 2004, Bill Davidsen wrote: > > > Is there no reasonable way to avoid using it in ACPI? It's not as if > > performance was critical there, or the code gets run often. Too bad it > > can't just be emulated like floating point, but I don't think it can on SMP. > > Well, "cmpxchg", "xadd", etc. can be easily emulated with an aid of a > spinlock. With SMP operation included. Clearly they can be replaced with inline code, as for catching the ill-op fault and emulating inline, I want to think about that a bit on SMP, in the case where multiple CPUs are accessing different locations, one is in kernel and one in user mode, etc. If it can be emulated safely in all cases, then that provides an out for the 386 case. To be useful it would have to be correct for all combinations of SMP, preempt and an interrupt and any point. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - 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/