Messages in this thread | | | Date | Wed, 25 Nov 1998 16:15:11 +0100 (CET) | From | Arjan van de Ven <> | Subject | Kernel Compilation Project |
| |
Hi,
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/
| |