public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: "Mike Frysinger" <vapier.adi@gmail.com>
Cc: "Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: the Linux kernel, testsuites, and maybe *you*
Date: 02 Sep 2007 00:08:57 +0200	[thread overview]
Message-ID: <p733axyxcli.fsf@bingen.suse.de> (raw)
In-Reply-To: <8bd0f97a0708311422u309ff09cs24dfe64ff535a982@mail.gmail.com>

"Mike Frysinger" <vapier.adi@gmail.com> writes:

> is there any sort of standard for testing and integration into
> mainline ?  

Everybody does their own.

> in the Blackfin world, we've been developing little
> external kernel modules and adding them to our own testsuite, but
> often times these things are not Blackfin specific.  case in point,
> we're integrating a string testsuite to make sure all of the fun str*
> and mem* functions are sane and operate as they expected, but rather
> than having just Blackfin benefit here, i'd like to see this pushed
> upstream ...

I would like to see this too. I wrote a couple of unit tests
during x86-64 development too and they would be handy
to have in a central place.

The SUSE kernel also has a crasher module that exercises the
allocators and is pretty useful to stress code in general.

Disadvantage is that test code tends to be hackish and ugly
and very specialized and will probably not pass standard review procedures.

Also the rt people seem to have pushed a couple of tests in already, 
but I always hated it that they're in the standard directories.
RCU also has, in fact they added a "eat all my CPU in tests"
CONFIG option. Just making that dependent on a CONFIG_UNIT_TESTS
would be a good change in itself. And then there are the slab
failure inducers of course.

BTW string functions are best tested in user space. That's
a relatively bad example.

-Andi

  parent reply	other threads:[~2007-09-01 22:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-31 21:22 the Linux kernel, testsuites, and maybe *you* Mike Frysinger
2007-09-01  6:14 ` Robin Getz
2007-09-01 22:52   ` Mike Frysinger
2007-09-01 22:08 ` Andi Kleen [this message]
2007-09-01 22:50   ` Mike Frysinger
2007-09-02  6:59     ` Andi Kleen
2007-09-02 15:15       ` Mike Frysinger
2007-09-02 15:43         ` Andi Kleen
2007-09-04 15:05           ` Mike Frysinger
2007-09-05 17:51             ` Mike Frysinger
2007-09-02 18:20       ` Håvard Skinnemoen
2007-09-04 14:41   ` Robin Getz
2007-09-02  2:34 ` Bill Davidsen
2007-09-02  3:44   ` Mike Frysinger
2007-09-03 13:37     ` Bill Davidsen

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=p733axyxcli.fsf@bingen.suse.de \
    --to=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vapier.adi@gmail.com \
    /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