Re: Linux 2.4.26-rc1 (cmpxchg vs 80386 build)

[Len Brown <len.brown@intel.com>]

On Sun, 2004-03-28 at 10:24, Arkadiusz Miskiewicz wrote:

> ACPI uses cmpxchg so it's not possible to build it for i386 it seems.
>
> +__acpi_release_global_lock (unsigned int *lock)
> +{
> +       unsigned int old, new, val;
> +       do {
> +               old = *lock;
> +               new = old & ~0x3;
> +               val = cmpxchg(lock, old, new);
> +       } while (unlikely (val != old));
> +       return old & 0x1;
> +}
> 

> -o vmlinux
> drivers/acpi/acpi.o(.text+0x4cf4): In function
> `acpi_ev_global_lock_handler':
> : undefined reference to `cmpxchg'
> drivers/acpi/acpi.o(.text+0x4dc6): In function
> `acpi_ev_acquire_global_lock':
> : undefined reference to `cmpxchg'
> drivers/acpi/acpi.o(.text+0x4e4b): In function
> `acpi_ev_release_global_lock':
> : undefined reference to `cmpxchg'

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 guess it depends on why one would build
for 808386 and CONFIG_ACPI=y.  Certainly
there is no risk of 80386 hardware actually
running the CMPXCHG in the ACPI code --
80386 was EOL'd long before ACPI came out
and 2.4.25 (and earlier) would have died on us.

I don't like #1 b/c I don't want to get more
e-mail like this;-)

#2 wouldn't bother me.  But if somebody is
building for i386 for the purpose for de-tuning
the compiler and they really do want ACPI support,
it would bother them.

#3 would be the old behaviour, which also
wouldn't bother me.  I guess we'd duplicate the
macro inside the ACPI code so that others didn't
use it by mistake.

#4 would be an academic exercise, since the code
would never actually execute on an 80386.

suggestions?

thanks,
-Len