Messages in this thread | | | From | "Russell Coker - mailing lists account" <> | Date | Wed, 16 Jul 97 22:16:52 +1100 | Subject | Re: 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
| |