lkml.org 
[lkml]   [2000]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.073 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site