From: Christoph Hellwig <hch@infradead.org>
To: Jack Stone <jwjstone@fastmail.fm>
Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] Regression testing framework for the kernel
Date: Mon, 11 May 2009 05:44:12 -0400 [thread overview]
Message-ID: <20090511094412.GA3665@infradead.org> (raw)
In-Reply-To: <1241125556.12894.1313160577@webmail.messagingengine.com>
On Thu, Apr 30, 2009 at 11:05:56PM +0200, Jack Stone wrote:
> Hi All,
>
> I would like to suggest a new framework to test the kernel. This
> framework would have the following goals:
> * Only runs at build time and has no effect on running kernel
I don't think we should ever run tests at build time unconditionally.
If we want to integrate it with make it should at least be a separate
make check.
> The best way of acheiving this that I have thought of it to compile the
> kernel source in question and
> to link it with special framework files. These files would serve two
> purposes: to provide the main function
> of the program and to provide the missing symbols for the kernel code.
> This would allow the replacement of
> certain functions in the code. For example replacing the spin_lock and
> spin_unlock functions would allow the
> locking behavior to be checked.
That's going to be a lot of stubs if we want to have a wide coverage.
Then again people are alredy doing this in various places, either with
the code in-tree but not easily buildable or out of tree, so having
all this in a common place and a common test driver would be a defintive
improvement. The right approach would probably be to add stubs on a
as-needed basis instead of trying to provide full coverage.
> Usage examples:
> * Test the behavior of a device driver
> As various kernel functions can be overridden a test case could
> be written to simulate a given device and
> check that there are no regressions in the driver
Not sure that is a good use. If we want to emulate hardware I think
we're better of using qemu for it and run a normal kernel under it.
> * Regression testing
> Any time a regression is found and fixed in the kernel a test
> case could be written to check that the
> regression does not reoccur later on.
I think that is the primary use case. Regresion-tests for library-ish
code that doesn't require much global state.
next prev parent reply other threads:[~2009-05-11 9:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-30 21:05 [RFC] Regression testing framework for the kernel Jack Stone
2009-05-11 9:44 ` Christoph Hellwig [this message]
2009-05-11 14:15 ` Jack Stone
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=20090511094412.GA3665@infradead.org \
--to=hch@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=jwjstone@fastmail.fm \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.