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

[Willy Tarreau]

> > OK, so why not compile the cmpxchg instruction even on i386 targets
> > to let generic kernels stay compatible with everything, but disable
> > ACPI at boot if the processor does not feature cmpxchg ? This could
> > be helpful for boot/install kernels which try to support a wide
> > range of platforms, and may need ACPI to correctly enable interrupts
> > on others.
> >
> > Cheers,
> > Willy
> >
> 
> Because it would get used (by the compiler) in other code as well!
> As soon as the 386 sees it, you get an "invalid instruction trap"
> and you are dead.

That's not what I meant. I only meant to declare the cmpxchg() function.
Nobody uses it in 386 code right now, otherwise this code would not compile
on 386 (like ACPI now). So the function would not be used by anything else
but ACPI (at the moment). Then, drivers (such as ACPI) who know they will
need cmpxchg() would be responsible for testing the flag upon initialisation
and refuse to complete initialization if the instruction is not available.

> It might be a good idea to declare that after version xxx,
> '386 compatibility is no longer provided. There is plenty of
> usability for '386s in 2.4.nn, for instance.

I don't like the idea of dropping 386 compatibility in the stable
series. For instance, my home firewall still was a miniature 386sx
a few months ago, so there may be other people in similar situation.
Making CONFIG_ACPI depend on CONFIG_CMPXCHG would be less of a hassle
in this case, because it would imply that people either compile for
486+ with ACPI or for 386+ without ACPI.

Cheers,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/