lkml.org 
[lkml]   [1998]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectKernel 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/

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