lkml.org 
[lkml]   [1998]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel Compilation Project
Hi Arjan.

> 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.

These are my personal thoughts on the comments therein...

> 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.

A few points here...

1. Before any combinations that are known to fail are tried, it
would be wise to find a combination that's known to compile
OK so as to prove that it is possible to compile the kernel
in question with the tools at hand.

2. The combinations tried must be ones that could actually be set
by a human user running "make config" or one of the other
variants.

Indeed, one way of making sure of that might be to add some sort
of "make randomconfig" option that goes through the options in
the same way that "make config" does, but chooses an answer at
random out of those available, rather than asking the user for the
desired choices. I can see how to do that for options such as
"bool", "tristate" or "dep_tristate", but how would such a system
deal with "int", "hex" or "choice", or other suchlike options?

> 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.

The maths is definately a bit out: Whilst each option may depend on
not more than five other options, those aren't necessarily the same
five other options, so the maths wouldnae be as simple as 2^(N+1) as
appears to be assumed there - (N+1)^N is probably nearer the mark,
although I'm no statistician...

> 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/...

I think that's already been answered...

> 2) What would be nice distributed setup

One that works and people are happy with, otherwise it matters
little...

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/

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