Date:	Sun, 22 Nov 1998 13:59:35 +0100 (CET)
From:	Arjan van de Ven <arjan@stack.nl>
To:	Linux Kernel <linux-kernel@vger.rutgers.edu>
Subject: Linux Kernel Compilation Project [proposal]

				proposal

			Kernel Compilation Project    

	 		Concepts and Requirements

	Arjan van de Ven
	arjan@stack.nl

------------
Introduction
============

The Kernel Compilation Project is based on complaints on the linux kernel 
mailinglist and on the mozilla project. The basic goals are to improve the
compilability of the Linux Kernel and the overall quality of the Kernel.
The idea behind this is that a failure to compile often indicates a bug
that has to be fixed.

The basic foundation is that when a kernel-change occurs (such as the
timeout-handling in 2.1.126-2.1.128), the new Linux Kernel will not compile
for some people because it contains not-updated, buggy, (driver)code.  
(for example the ftape-driver in the timeout-case)

-------------------
The Mozilla Project
===================

The Mozilla-project suffered some of the same issues and now has a policy
to accept patches only when the resulting code compiles for all platforms,
and has an automated system to handle this. 

This good-or-bad strategy does not work for Linux, for several reasons:

(1) The number of possible "platforms" (configurations+platforms for Linux)
    is way to high for Linux, compiling all combinations would take
    indefinitly.

(2) Linus determines what goes into the kernel, not some computer-program.
    This is better, in this way it is possible to include a definite
    improvement, even if some drivers are not updated yet or are buggy by
    design. There is no substitute for human intelligence.

--------------
The Linux case
==============

For the Linux Kernel, a "compilability" measure should not (absolutely)
determine if a patch (or a batch of patches) should be included into the
kernel, but should pinpoint problem areas, as in "things to do".

This will improve the quality of the Linux Kernel because bugs are found in
an early stage, and, more as a side-effect, some design-flaws and bugs are
found by the failure to compile some non-realistic kernel configuration.

It is not possible to try to compile all possible kernel-configurations, but
it is possible to achieve a reasonable approximation by compiling a small
number (say 10 or 20) of "random" configurations. In the ideal-case, someone
will dedicate a machine to this task, which means that the actual number
achieved will only depend on the release-speed of the kernels.

------------
Requirements
============

(1) A system that creates a random (but valid) kernel configuration. 
    I have created such a system in a simple way, until a better way is
    devised, it is usable (and yields some interesting results).

(2) The kernel should compile well for random configurations.
    For new bugs to be found, most old bugs will have to be resolved first.
    This was not the case when I started trying for 2.1.125. Several patches
    I made are included in the newer kernels, resulting in a (slightly) better
    compilability for 2.1.129 (with the AC-patches applied). I have several
    other patches that improve the compilability greatly, but most are
    somewhat "dirty" and rejected by Alan Cox (or at least not used).

(3) A system that gathers the results without user interaction and puts them 
    (preferably) on a website in a way developers can try to fix the found 
    problems. 
    I will look into this when this project is considered a good idea by the 
    linux-kernel community.

(4) Linus should recognize the fact that this project improves the quality
    of the kernel and maybe even start using the concept. It might be a good
    requirement for the 2.2preX kernels to always compile.


-------------------
Preliminary results
===================

I have created a simple system to create random (but valid)
kernel-configurations, and during the testing of this system, several (>20)
problems have been resolved. The current status is that the 2.1.129 kernel
compiles about half the time, provided both the AC-patches and mine are
applied. 

Most solved problems deal with:
* Drivers depending on /proc, while it is not selected by the users
* Drivers depending on tcp/ip 
  (usually a network-model violation, i.e. hardware-drivers trying to send
   IP-packets)
* Drivers depending on parallel-port support (ie bugs in Config.in)
* Nameclashes
  (for example the pms card and the i2c-driver [fixed in 2.1.128])
* Incorrect dependencies 
  (for example, sony535 depends on network-code for auto-irq but this is
   never declared in the makefiles)
* Plain bugs and typo's
  (for example the file drivers/net/hamradio/6pack.c, line 729)

----------
Discussion
==========

Advantages
+ Several bugs are found in an early stage (for example, the ftape-thing in 
      2.1.126 would have been detected and fixed before the release)
+ The kernel would (almost) always compile, so new users always get a 
      compiling kernel if they build one of their own
+ The overall quality of the kernel will improve, as well as the perception
      of the quality of Linux in general for the non-kernel-hacker.

Disadvantages
- It takes some effort now to straighten out the current non-compilation
  issues and bugs (but wouldn't that be a great idea for 2.2preX anyway)
- Several of the bugs found now will be found in a later stage anyway, 
  so why bother putting in the effort
- It takes some computer-resources to compile a series of kernels 
  (my machine [K62-300,128mb Ram] takes about 8 minutes for a
   kernel-compile)
- The 2.1.X kernels are "development" kernels, so they are allowed to be
  "broken"




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