} Andrea Arcangeli <[EMAIL PROTECTED]> said:
} > 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.
}
} Oh, come on. The kernel (or glibc for that matter) is not about "inline
} asm()" at all! That is a tiny fraction of each. The kernel is different in
} that it has lots of hardware-dependent code, which leads to some rather
} strange contortions in C in order to be able to _avoid_ asm. The kernel
} also moves forward a lot faster than glibc, and grows a lot. A bug in glibc
} means an application goes down or screws up, a bug in the kernel can mean
} masive data loss in no time at all.
I don't think I understand your point. Are you saying that gcc cannot be
expected to keep up with the ways in which the kernel uses it? My argument
is that providing a compiler that actually regresses (old version compiles
kernel, redhat 7.0 included one does not) is not a good choice.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
