Re: Re[2]: Kernel testing

Seth M. Landsman (seth@job.cs.brandeis.edu)
Sat, 12 Apr 1997 11:14:10 -0400 (EDT)


On Sat, 12 Apr 1997, Dave Wreski wrote:

> > > That it is unnecesarily complex, and you can only report success, anyway.
> > > If it crashes, you can't expect that machine to report it :-).
> > > [You need human beings in this process...]
> >
> > We could use an ACK type of system. If we have an identical test
>
> I think that unless we come up with some ideas on how to implement this,
> we should drop it.

Implementation isn't difficult. Read my idea about sticking
something in the rc.M file ...

> 1. How are we going to implement issues like timings? Think about the
> recent TCP-stall problem for one.

What makes you think that we can implement a test that is manual
any better?

> 2. According to this ACK scheme, how are we to tell how long something
> should take before giving up? Different times for different boxes?

Reasonable amount of time. This can be calculated on the fly or
we can set a maximum limit.

> 3. Isn't security an issue? Do you think we will be able to provide
> kernel-level control and have some sort of secure environment, so we don't
> hear another one of McAffee's "Linux's first virus!" messages?

Of course the testing suite will only be used by people who know
that they are using it, know what is being used and know what might
happen. I think it would be a wonderful idea to include some of the minor
tests, such as ensure system calls do what they should be doing as part of
the kernel suite (make test idea), but the stress tests are something
different.

> I could go on. I don't think the developers will go for such an idea.
> Show us some code, then maybe they will listen.

I think we need to hash the idea out first. What would you see as
the optimal way to test the kernel, ensure that we get all the necessary
data and get the most thorough, standardized testing possible? The issue
of sending it automaticly or manually is trivial. Sending it without the
user's knowledge is best for the developers because it ensures that
everything gets there, without fault. Manually might be preferred by the
user. A commandline switch should make everyone happy ...

-Seth