public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: nbecker@fred.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: regression testing
Date: 23 Mar 2001 03:11:02 -0700	[thread overview]
Message-ID: <m1wv9g23t5.fsf@frodo.biederman.org> (raw)
In-Reply-To: <x88zoeeeyh8.fsf@adglinux1.hns.com>
In-Reply-To: nbecker@fred.net's message of "22 Mar 2001 08:15:31 -0500"

nbecker@fred.net writes:

> Hi.  I was wondering if there has been any discussion of kernel
> regression testing.  Wouldn't it be great if we didn't have to depend
> on human testers to verify every change didn't break something?

There is a some truth to this.  However for kernel development there
is one thing to keep in mind: most bugs are in the drivers (buggy
hardware with a software workaround counts as a driver bug).  Having
an army of human testers with weird machines with all kinds of
drivers is the only economical way of doing driver regression testing.

> OK, I'll admit I haven't given this a lot of thought.  What I'm
> wondering is whether the user-mode linux could help here (allow a way
> to simulate controlled activity).

The most devastating bugs are in the core kernel code, and a
regression test for that code is more likely.  Yes user-mode linux
could help here (you could stress test the core kernel without worry
that when it crashes your machine will crash as well).  

Additionally a good test suite that give the kernel a good going over
in a manner that exercises standard kinds of hardware could also help.  

Unless you are using profiling to verify you have covered all paths
in the code there will always be question such as does that code path
work in practice.

The other thing that can help a lot looks like the augmented static
analysis of the kernel.  Once that is generally available we should
be able to verify at compile time that a lot of little rules are
always obeyed.  It will never get the really hard things but the
compiler pointing out that there is an sti on all paths after a cli
could improve things significantly (especially with the drivers).

Eric

  parent reply	other threads:[~2001-03-23 10:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-22 13:15 regression testing nbecker
2001-03-22 13:39 ` Richard B. Johnson
2001-03-22 13:47   ` nbecker
2001-03-22 14:47   ` Alan Cox
2001-03-22 14:45     ` Richard B. Johnson
2001-03-22 18:18   ` Cort Dougan
2001-03-22 15:13 ` Wade Hampton
2001-03-22 15:56   ` Nathan Straz
2001-03-22 16:46     ` Nathan Dabney
2001-03-22 16:37 ` Rik van Riel
2001-03-22 18:21   ` Cort Dougan
2001-03-22 18:12 ` Jonathan Morton
2001-03-23 15:00   ` Horst von Brand
2001-03-23 15:29     ` Rik van Riel
2001-03-23 10:11 ` Eric W. Biederman [this message]
2001-03-27  7:21   ` Werner Almesberger
  -- strict thread matches above, loose matches on Subject: below --
2001-03-22 18:44 Torrey Hoffman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1wv9g23t5.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nbecker@fred.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox