Messages in this thread | | | Date | Thu, 4 Feb 1999 11:38:27 +0000 | From | Alain Williams <> | Subject | Re: Kernel interface changes (was Re: cdrecord problems on recent Linux versions) |
| |
On Wed, Feb 03, 1999 at 07:31:50PM -0500, Monty wrote: > And, once the bugs were found, they were fixed. That also isn't my > problem. My problem is that in the meantime, in a subminor release, > libc was made incompatable with all previous version in a fundamental > way. *No* program dynamically linked against a previous version would > function any longer because the lookup tables in the compile-time > headers changed. This is not a minor bug! Nor has this kind of bug > been a rarity. > > *That* is my problem.
It sounds that what is needed is some sort of formal regression testing: * A complete test suite that would exercise every part of Linux. This would help find problems introduced by patches quickly & cheaply (CPU time is cheap). * This must be for *everything*, not just the kernel, but also for major components (eg: modules, libc, samba, vim, ...). * Source and binary tests need to be made. * Device driver tests need to be done -- this is important, just plugging it in & using it doesn't prove much, many bugs lurk in the corners of operation (eg: large packet size, high interrupt rate, ...) * Tests should not just be to ensure that things work, but that they fail when they should and report errors properly. * These tests can be run on the different platforms, with different hardware configurations.
This is much more than just a kernel issue, but the kernel is one imporant part. The development of the tests could/should be done in parallel by the separate development groups, what would be useful is a common set of tools to do this.
Note: there are occasions when incompatible changes *have* to be made (eg a security fix), in that case the testing will identify what will be broken by the change and it can be properly documented. All other incompatible changes should be saved up and released all at once in a major release (eg 2.0 -> 2.2).
It will be hard work to do this, but the effort will be repaid many times over once it is done -- the only ones to suffer will be the makers of brown paper bags.
Volunteers for kicking this off ?
Cheers
-- Alain Williams
- 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/
| |