lkml.org 
[lkml]   [1997]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 2.0.31 : please!
>> > 10 people. Some of the bugs that show up in 2.0.x show up in configurations
>> > that maybe 1 in 1000 or 1 in 10,000 users have and perhaps only after a
>> > week of continual load. On a 10 user sample 2.0.30 is probably rock solid
>>
>> This is not valid for what I said about development kernels. In order to
>> test if it compiles, it is only necessary to turn on all options that
>> are not mutually exclusive and compile. Kernels 2.1.29 up to 2.1.41 (I

>What to do with mutually exclusive options? Compile it with A enabled and
>B disabled, and another time with A disabled and B enabled?

Do several compilation runs. To eliminate module problems you would
need to compile many items as modules and into the kernel. When compiling
as modules you'll have to boot the kernel and run "depmod -a", however this
doesn't solve the case where 2 modules depend on a kernel symbol which is
only exported because of one of the modules (ie if A is module then it's
exported but if B is a module then it isn't - lots of potential for this in
netsyms.c). So we can't do this perfectly.
However I believe that if we compile a significant number of different
kernel configurations on an architecture without problems then the chance
of someone experiencing a compilation problem on that architecture is very
low. I think that ~30 different kernel builds which are methodically
designed will sort out many of these problems. That's probably 6 hours of
work per kernel release, but if we split it up amoung a dozen people then
it'll only be ~30mins each. Another advantage of splitting it up amoung 12
people is that when a kernel is released the chance is that someone will
complete their 30mins of testing within a few hours of the release and post
the results. If something is seriously wrong then it should be found
quickly and reported in enough detail that skilled people can fix it.

>There are _lots_ of options that have small influences on each other.
>Compiling kernels for all combinations will take much time...

There are over 20 Y/N or Y/M/N questions involved in a "make config".
This means over 1 million different combinations of kernel parameters. If
it takes 5 minutes per kernel then that's over 10 years of compilation
time.
It's not possible to test all combinations of kernel options, but if we
test an intelligently designed sub-set then we should be able to find most
bugs that can result in compilation errors.

>> I do realize that. I'm saying there should be at least *SOME* sanity
>> checks before releasing even a "development" kernel.

>It ran on Linus' machine, which is one sanity check.

>> Like I said, I would volunteer to test-compile 2.1.X kernels.

>Have fun :-)

>And don't forget to compile kernels for other architectures than ix86 ;-)

I am prepared to join in testing 2.0.x and 2.1.x kernels. I am not able
to test on any platform other than x86. However from my recollection of
reading bug reports, trying to fix kernel bugs myself, and having systems
crash on me for various reasons, the worst bugs are in kernel memory
management, networking, and device drivers. The memory management is
slightly platform-dependant, but the rest is common to all platforms. A
solid x86 kernel is a great reliability benefit for other platforms IMHO
(if something works on one platform but fails on another then that must be
an indication of where the problem lies).


Russell Coker

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