Re: too much untested code in new kernels

David S. Miller (davem@jenolan.rutgers.edu)
Fri, 3 Jan 1997 19:30:41 -0500


Date: Fri, 3 Jan 1997 10:16:47 -0600
From: "Ray Van Tassle-CRV004" <Ray_Van_Tassle-CRV004@email.mot.com>

JESUS H. CHRIST! Why don't you learn to read before blasting off
your mouth?

I was a shoe-lace ahead of you when I made my statements aparently.

I specifically said "one compile with everything on" and you
_persisted_ in reading this as "trying every possible configuration
the kernel can be done with, on every supported platform".

As Richard has pointed out such a "everything on" build is impossible,
especially on Intel and Alpha. This is due to:

a) drivers or other configurable parts of the system being
mutually exclusive to each other

b) some configurable items not supporting being compiled
as modules and some that do

c) kernel size on certain platforms is perhaps limited in
some way, even if every driver could be compiled
in a non-modularized manner into the kernel, the kernel
image size limitation would prevent an "everything" build

So therefore it would require more than one "everything configured in"
build since such a thing is impossible. Apply some combinatorial
theory to this situation, determine the number of configurable options
total, then determine at most how many of them you can get into a
build at once and which ones (try to make this number as high as
possible). Use those things to determine how many builds a developer
must do to get the full coverage that you are in fact asking for. I
would guess that this number is relatively large.

Therefore it still stands that your request is unreasonable.

If this sort of responsability should be applied, it should be done at
the per maintained piece of code level, not globally. So it is not
all that unreasonable to ask this of say a driver maintainer. But
when you start entering territory such a the loadable modules code, it
is very difficult for the person making these changes to get at enough
platforms to be reasonably sure that his changes are well tested and
will not break too much on platforms other than what he primarily
works on.

Granted, I would have liked that the new module utilities had been
released (publicly on linux-kernel, even if in beta form) before the
kernel level changes went in. But this happens some times, and we
caught it obviously, and it is being worked on. Isn't this how it
always has worked?

---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><