> We could use an ACK type of system. If we have an identical test
>suite for every system, we can have the suite send something to the effect
>of "Starting test 1" and then "Test 1 succeeded", etc. If we get a
>"Starting test x", but no "Test x succeeded", we know exactly where things
>went wrong. Also, diagnostic messages that get spit up every so often
>could contain important information which will get transmitted.
Not to offend you, but before learning to fly you normally have to
learn to walk: I'd suggest we _first_ build a test suite and
afterwards think about how to distribute it on the network.
So let's stop discussing how to internetwork a test suite and start
brainstorming about how to build a real test suite:
- Write a framework for tests
Set up an environment that allows new kernel tests easily to be
integrated. Have a look at dejagnu, maybe that fits just fine.
- Check all kernel services for correct interfaces
Write test programs that test syscalls, /proc fs, user
file systems etc. for behaving as documented.
As already mentioned the Posix conformance suite might be a
good thing to start with, if only to see how such tests can
be written.
- Check for known errors
Try to reproduce each kernel bug that gets known within the
test suite. This ensures every bug will only happen once in
the lifetime of Linux.
- Abuse the kernel in every twisted way
Put stress on the kernel, by running crashme, the parallel
badblocks script from the kernel mailing list FAQ, network
performance testers and other stress tests ...
- Make the whole thing so simple and easy to use that developers
will use it to test their brand new code by writing their own
tests.
Froh
-- Frohwalt EgererOne does not "choose" the Emacs. Rather, it is the Emacs, which, in Its infinite wisdom, chooses us. Wash your mouth out and pray to the Emacs for forgiveness.
In the Name of the Emacs, the Rmail and the Holy Gnus.
-- Ashraf Ahmed in alt.religion.emacs