lkml.org 
[lkml]   [1997]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel testing
On Mon, 14 Apr 1997 Eric.Schenk@dna.lth.se wrote:

>
> "Seth M. Landsman" <seth@job.cs.brandeis.edu> writes:
> >On 14 Apr 1997, Miguel de Icaza wrote:
> >> The test suite then could actually stress test the kernel code without
> >> even booting the kernel.
> >
> > Exactly. It would save a whole lot of problems for many people if
> >they could test the integrity of the kernel before they installed it.
> >This wouldn't save everyone from installing a kernel that didn't boot, but
> >it would save some ...
>
> Note that while this will catch a certain class of errors, it will won't
> do much to catch race conditions or broken hardware initializations
> which only occur when the kernel is booted live.

There is a very large class of errors that will be totally missed.
Of course hardware problems will be missed in most cases, probably race
conditions as well.
That isn't to say that we won't find a bunch of errors that will
catch hardware problems and the like.

> If you're kernel won't boot it's often because of a race condition
> or some stupid hardware initialization. Still, ex-suiti (is that even a
> word?) testing ofvarious critical kernel routines is a good idea,
> expecially if the way they are tested is to write a bit of code
> that calls the routine and tries to force it to do something wrong.

Exactly.

> We can always accumulate such bits of testing code over time as we
> spot errors in the kernel. It does take a bit more effort on the part
> of developers who must also write new testing when they discover a
> kernel bug, but you often end up writing a good bit of such code anyway
> to test your theories about what is really going on in the kernel.
>
> The same can be said for collecting bits of code that are used to test
> a running kernel.

Three thoughts ...

First, this testing idea has two schools of thought, both of which
should be implemented in time. One idea is that we are testing
compatibility with the kernel and your machine. Second is that we are
beating the crap out of your machine and the kernel to find hardware
errors in your machine and load / time sensitive errors in the kernel.
The first school is the easiest to implement, I think, and will have the
largest base of people to use it, as it won't break their machine.

Second, developers probably build stub modules to test out their
drives and modifications. Would they be willing to let us have these
stubs for inclusion?

Third, what about the module facility for testing? i.e., person
builds a new kernel. Person's old kernel has module support. Can we have
the old kernel load up bits and pieces of the new kernel for testing
purposes?

-Seth


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.035 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site