On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote:
> I honestly see nothing wrong with it. There are different parts of
> the compiler stressed by the kernel build as opposed to most userland
> compilation, and furthermore the desired compiler stability/feature
> ratio is different for each task. [..]
Many userspace sources are using spinlocks and atomic SMP locking in inline asm
just like kernel (I think glibc does that for pthreads too). Inline asm _must_
be 100% reliable not only for kernel. There's nothing foundamentally different
between userspace and kernel needs, it just happens that "often" userspace is
single threaded, doesn't need any atomic operation and in turn stresses the
compiler much less then the kernel on that side.
I disagree the stability/feature ratio needs are different between kernel
and userspace (at least excluding the FPU handling that of course doesn't
matter for kernel :).
> [..] So one way to solve these differing
> needs is to simply use different compilers.
Now if the kernel is buggy then let's fix it, this is a start:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.18pre15aa1/80_smp-locking-1
There may be a timeframe where the kernel needs to cameup with the fixes that a
new correct compiler optimization can trigger (as it happened with egcs for
example), but once those kernel bugs are fixes there's no point in having two
different compilers and having only one will for sure increase the testing and
in turn the robusteness of it as well as the correctness of the kernel. I
don't think the kernel-compiler-toolkit way of the other unix is the best one.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:21 EST