All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Jason Wessel <jason.wessel@windriver.com>,
	Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH 2/2] selftests: New x86 breakpoints selftest
Date: Thu, 8 Dec 2011 01:11:41 +0100	[thread overview]
Message-ID: <20111208001138.GD13252@somewhere.redhat.com> (raw)
In-Reply-To: <20111207153223.4885bab9.akpm@linux-foundation.org>

On Wed, Dec 07, 2011 at 03:32:23PM -0800, Andrew Morton wrote:
> On Fri,  2 Dec 2011 16:41:15 +0100
> Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 
> > Bring a first selftest in the relevant directory.
> 
> That all looks nice and simple, thanks.  Unless I get suitably shouted
> at I think I'll send all this Linuswards.  Then I can hassle people to
> add their little test snippets as they add userspace-visible features.
> 
> I don't think we'd ever want to turn this into some huge kernel
> verification suite.  My thinking here is that I frequently see that
> people have written little test cases for their new feature, but those
> test cases just die after the feature is merged.  It would be better to
> maintain and grow these tests as the relevant features are augmented or
> bugfixed.

Exactly. And I also think this is no good place for background long running
stress-tests but rather for correctness tests (Unless we find situations
where short stress-tests are enough to trigger correctness problems).
That's really targeted to spot ABI breakages or alike.

My selftest for the cgroup task counter subsystem is also a good candidate for
that (if that subsystem ever get merged but that's a separate debate ;)

> 
> All these features are Linux-specific.  Standard interface features (eg
> POSIX) are and should be tested via other externally-maintained test
> suites.
> 
> If the whole idea ends up not working out, we can just delete it all.

Agreed, let the selftest subsystem selftest itself for a while and we'll figure
out.

Thanks.

  reply	other threads:[~2011-12-08  0:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-02 15:41 [PATCH 1/2] selftests: New very basic kernel selftests directory Frederic Weisbecker
2011-12-02 15:41 ` [PATCH 2/2] selftests: New x86 breakpoints selftest Frederic Weisbecker
2011-12-07 23:32   ` Andrew Morton
2011-12-08  0:11     ` Frederic Weisbecker [this message]
2011-12-12  6:06   ` K.Prasad
2012-01-13 18:54 ` [PATCH 1/2] selftests: New very basic kernel selftests directory Fubo Chen
2012-01-17  1:49   ` Frederic Weisbecker

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=20111208001138.GD13252@somewhere.redhat.com \
    --to=fweisbec@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=jason.wessel@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.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 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.