>> However, as I see it, a selection of just THREE of the many
>> combinations of options should detect MOST of the problems that
>> prevent the kernel from compiling. These may not produce useful
>> kernels, but they would be useful as test cases because of this
>> property.
>> Incidentally, I've tried all three of the above on my system,
>> using the raw 2.0.35 source tree, and NONE of them compiled
>> without an error causing them to crash out.
> Maybe the following is a good idea to improve the quality of the
> kernels: Have one or more machines doing nothing but compiles on
> the latest kernel, using (semi)random configurations (1).
> It might even be possible to automate the bugreporting caused by
> this in a bug-tracking system that checks if errors in a previous
> version are fixed in the new version of the kernel, and maybe even
> some stats (like what parts contain the most problems).
> If the major kernel-people (Linus, Alan, DavidM etc) think this is
> a good idea, I'm willing to put some time into this....
> (1) Mozilla uses a similar approach, where patches are accepted
> only when the beast compiles.
I'd certainly say "go for it", since such an approach can only help to
get rid of the remaining bugs, and I may even be able to arrange a
system with a 24/7 connection to do it, although I can't currently
guarantee that...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/