From: Willy Tarreau <willy-tRhHnHjXm5DYtjvyW6yDsg@public.gmane.org>
To: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Arkadiusz Miskiewicz
<arekm-k0Z414SquRyhPH1hqNUYSQ@public.gmane.org>,
Marcelo Tosatti
<marcelo.tosatti-3EexvZdKGZRWk0Htik3J/w@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ACPI Developers
<acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: Linux 2.4.26-rc1 (cmpxchg vs 80386 build)
Date: Mon, 29 Mar 2004 07:22:38 +0200 [thread overview]
Message-ID: <20040329052238.GD1276@alpha.home.local> (raw)
In-Reply-To: <1080535754.16221.188.camel-D2Zvc0uNKG8@public.gmane.org>
Hi Len,
On Sun, Mar 28, 2004 at 11:49:15PM -0500, Len Brown wrote:
> ACPI unconditionally used cmpxchg before this change also -- from asm().
> The asm() was broken, so we replaced it with C,
> which invokes the cmpxchg macro, which isn't defined for
> an 80386 build.
>
> I guess it is a build bug that the assembler allowed us
> to invoke cmpxchg in an asm() for an 80386 build in earlier releases.
>
> I'm open to suggestions on the right way to fix this.
>
> 1. recommend CONFIG_ACPI=n for 80386 build.
>
> 2. force CONFIG_ACPI=n for 80386 build.
>
> 3. invoke cmpxchg from acpi even for 80386 build.
>
> 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 :
#ifndef CONFIG_X86_CMPXCHG
#ifndef CONFIG_SMP
#define cmpxchg(lock,old,new) ((*lock == old) ? ((*lock = new), old) : (*lock))
#else
#define cmpxchg(lock,old,new) This_System_Is_Not_Supported
#endif
#endif
This code (if valid) might be added to asm-i386/system.h so that we don't
touch ACPI code.
Any comments ?
Willy
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
WARNING: multiple messages have this Message-ID (diff)
From: Willy Tarreau <willy@w.ods.org>
To: Len Brown <len.brown@intel.com>
Cc: Arkadiusz Miskiewicz <arekm@pld-linux.org>,
Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
linux-kernel@vger.kernel.org,
ACPI Developers <acpi-devel@lists.sourceforge.net>
Subject: Re: Linux 2.4.26-rc1 (cmpxchg vs 80386 build)
Date: Mon, 29 Mar 2004 07:22:38 +0200 [thread overview]
Message-ID: <20040329052238.GD1276@alpha.home.local> (raw)
In-Reply-To: <1080535754.16221.188.camel@dhcppc4>
Hi Len,
On Sun, Mar 28, 2004 at 11:49:15PM -0500, Len Brown wrote:
> ACPI unconditionally used cmpxchg before this change also -- from asm().
> The asm() was broken, so we replaced it with C,
> which invokes the cmpxchg macro, which isn't defined for
> an 80386 build.
>
> I guess it is a build bug that the assembler allowed us
> to invoke cmpxchg in an asm() for an 80386 build in earlier releases.
>
> I'm open to suggestions on the right way to fix this.
>
> 1. recommend CONFIG_ACPI=n for 80386 build.
>
> 2. force CONFIG_ACPI=n for 80386 build.
>
> 3. invoke cmpxchg from acpi even for 80386 build.
>
> 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 :
#ifndef CONFIG_X86_CMPXCHG
#ifndef CONFIG_SMP
#define cmpxchg(lock,old,new) ((*lock == old) ? ((*lock = new), old) : (*lock))
#else
#define cmpxchg(lock,old,new) This_System_Is_Not_Supported
#endif
#endif
This code (if valid) might be added to asm-i386/system.h so that we don't
touch ACPI code.
Any comments ?
Willy
next prev parent reply other threads:[~2004-03-29 5:22 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <A6974D8E5F98D511BB910002A50A6647615F6939@hdsmsx402.hd.intel.com>
[not found] ` <A6974D8E5F98D511BB910002A50A6647615F6939-N2PTB0HCzHJF3Yvz3xaN/VDQ4js95KgL@public.gmane.org>
2004-03-29 4:49 ` Linux 2.4.26-rc1 (cmpxchg vs 80386 build) Len Brown
2004-03-29 4:49 ` Len Brown
[not found] ` <1080535754.16221.188.camel-D2Zvc0uNKG8@public.gmane.org>
2004-03-29 0:09 ` Andi Kleen
2004-03-29 0:09 ` [ACPI] " Andi Kleen
2004-03-29 5:22 ` Willy Tarreau [this message]
2004-03-29 5:22 ` Willy Tarreau
2004-03-29 7:01 ` Denis Vlasenko
[not found] ` <200403290901.47695.vda-so6tiL4DrmS23Ynj82S0jdyBExgiH1vWcG62WxB9dV4@public.gmane.org>
2004-03-29 9:56 ` Arkadiusz Miskiewicz
[not found] ` <200403291156.38961.arekm-k0Z414SquRyhPH1hqNUYSQ@public.gmane.org>
2004-03-29 11:31 ` Alan Cox
2004-03-29 19:57 ` Willy Tarreau
[not found] ` <20040329052238.GD1276-HkMpAodKYdnXX8ko2wsARw@public.gmane.org>
2004-03-29 11:05 ` Frank Mehnert
2004-03-29 22:07 ` Len Brown
2004-03-29 22:07 ` Len Brown
2004-03-30 12:56 ` [ACPI] " Alan Cox
2004-03-30 13:15 ` Richard B. Johnson
2004-03-30 14:22 ` Willy Tarreau
2004-03-30 14:48 ` Richard B. Johnson
2004-03-30 15:09 ` Willy Tarreau
[not found] ` <20040330150949.GA22073-HkMpAodKYdnXX8ko2wsARw@public.gmane.org>
2004-03-30 15:33 ` Richard B. Johnson
2004-03-30 15:33 ` [ACPI] " Richard B. Johnson
2004-03-30 16:14 ` Willy Tarreau
2004-03-30 16:42 ` Chris Friesen
[not found] ` <4069A359.7040908-hwFIcccggHZv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2004-03-30 17:44 ` Len Brown
2004-03-30 17:44 ` [ACPI] " Len Brown
2004-03-30 18:30 ` Arkadiusz Miskiewicz
2004-03-30 20:05 ` Len Brown
2004-03-30 20:25 ` Arkadiusz Miskiewicz
2004-03-30 21:49 ` Len Brown
2004-03-30 20:08 ` Bill Davidsen
[not found] ` <4069D3D2.2020402-sQDSfeB7uhw@public.gmane.org>
2004-03-31 11:13 ` Maciej W. Rozycki
2004-03-31 11:13 ` [ACPI] " Maciej W. Rozycki
2004-03-31 13:04 ` Bill Davidsen
2004-03-31 15:02 ` Jamie Lokier
2004-04-01 12:29 ` Maciej W. Rozycki
2004-04-01 13:17 ` Richard B. Johnson
2004-05-08 10:18 ` Denis Vlasenko
[not found] ` <Pine.LNX.4.55.0404011423070.3675-rsPqkUlH4Vdx0R2ya2r/wqsMm+1xrEX8@public.gmane.org>
2004-04-01 20:46 ` Len Brown
2004-04-01 20:46 ` [ACPI] " Len Brown
[not found] ` <1080852371.30349.19.camel-D2Zvc0uNKG8@public.gmane.org>
2004-04-02 10:54 ` Maciej W. Rozycki
2004-04-02 10:54 ` [ACPI] " Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040329052238.GD1276@alpha.home.local \
--to=willy-trhhnhjxm5dytjvyw6ydsg@public.gmane.org \
--cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=arekm-k0Z414SquRyhPH1hqNUYSQ@public.gmane.org \
--cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marcelo.tosatti-3EexvZdKGZRWk0Htik3J/w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.