Andrea Arcangeli <andrea@suse.de> 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.
[...]
> Now if the kernel is buggy then let's fix it, this is a start:
Alan has stated that he is open to patches that fix overoptimizations and
other such bugs in the kernel, sent it to him. So should H. J. Lu do with
his patches posted earlier today.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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