Messages in this thread |  | | Date | Wed, 11 Oct 2000 21:35:57 -0600 | From | Cort Dougan <> | Subject | Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI |
| |
} 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.
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |