![]() | |||||||||||||
Messages in this thread |
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 - 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/ | ||||||||||||
| Last update: 2005-03-22 13:02 [from the cache] ©2003-2008 | |||||||||||||