Thanks for your response to my proposal for a "Kernel Compilation
Project".
This message is intended to summarize the responses and give a progress
report.
Summary
=======
The common idea I get from the responses is that the thing should be
distributed. (if only for the different platforms Linux runs on)
There was a question about if all participents should use the _same_
compiler (i.e. gcc version 2.7.2.3.1.3.2.1.2.3.x) or that multiple
versions would be allowed. It is my opinion that the kernel should at
least _compile_ with all compiler-flavours, but to include the
compiler-version in a "bugreport" just to be sure.
Someone answered that he prefered a fixed set of configurations over a
random set, I partially agree: If a configuration is known to fail, it
should be put in some queue and tried first when a new kernel is released.
If it succeeds, it can be moved to a "fixed" section and never be used
again. Also, some fixed variants (all options "Y" and all options "N" for
example) should be tried for every kernel too.
About the math:
Some said that there were way to much options to ever test every
combination (no doubt about that) but the also true response was that a
certain option at most has some (let's say 5) other options it actually
depends/conflicts on, so trying about 64 kernels would make the
probability very small that something is missed.
64 seems a little on the small side (given that most options have 3
responses (Y/N/M) and most have a probability of 1/4 of beeing selected),
but the general idea is that the job is not _that_ endless.
Progress
========
I have set up a JitterBug bugtracking system on my website
( http//www.stack.nl/~arjan/cgi-bin/KERNEL ) and a shellscript/C system
that produces a random config, compiles it and mails the result to the
jitterbug-page. This is not really distributed (the .config's are created
on the client) but it is a start. It is currently in "beta-test", to see
if it can run unattended. The compiles in the testset ran on a slow 486
(at work), I'll port them to my K6 at home, it should increase the number
of reports.
Planning
========
1) Create a better system, distributed in that the configurations are
created in a central location (this requires a linux-box with the
kernel-sources and 24/7 net-connectivity)
2) Multi-platform support (is it possible to do a make config for a
different architecture?)
3) Distribution of patches along with the .config (for "try this config
on 2.1.130preXX")
Questions
=========
The following questions remain:
1) How should the found problems be reported to Linus/Alan/...
2) What would be nice distributed setup
Greetings,
Arjan van de Ven
PS: If someone wants non-guest access to the jitterbug-system, email me
and I'll set up an account.
-
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/