Messages in this thread |  | | Date | Fri, 3 Jan 1997 19:30:41 -0500 | From | "David S. Miller" <> | Subject | Re: too much untested code in new kernels |
| |
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 /_____________/ / // /_/ ><
|  |