> The news that 2.0.34 is soon to go live prompted me to suggest a method
> of testing the kernels and its drivers to ensure that bugs are stomped
> quickly.
>
> What if someone was to write a suite of test programs that exercises
> every aspect of the kernel and generates a report on problems found with
> the kernels and its associated drivers/modules. This could be one neat
> way to uncover bugs and automatically generate a bug report. Is this
> feasible or just impossible? For each new feature that goes into the
> kernel, one could add a test program to go with it and so on? It would
> be obvious that this test suite would not use libc or whatever, except
> for outputting results in order to avoid bugs in libc et. al from
> obscuring proper testing of the kernel.
>
> Comments, anyone?
I wrote a random syscall program, and a program that attempts to do
equivalence testing on syscalls (it just needs more data types and
syscalls declared, but the framework is there, and adding the
types/syscalls is very easy). E-mail me privately if you want the URL to
the source.
A regression test suite would be very nice, too, but I don't have time to
write one - you sound like the man ;-)
-- Elliot
When I die, I want to die peacefully in my sleep like my grandfather...
...not yelling and screaming like the people in the back of the
plane he was flying.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu