From: chrubis@suse.cz
To: Mel Gorman <mgorman@suse.de>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] kernel testing standard
Date: Thu, 5 Jun 2014 10:39:07 +0200 [thread overview]
Message-ID: <20140605083907.GA11139@rei.Home> (raw)
In-Reply-To: <20140605065455.GM10819@suse.de>
Hi!
> > > >> As LTP is reported to
> > > >> be sane these days for some tests, it could conceivably be wrapped by "make
> > > >> test" to avoid duplicating effort there. I think that would be worthwhile
> > > >> if someone had the time to push it because it would be an unconditional win.
> > > >
> > > > That is what I have been asking for for _years_. Hopefully someday
> > > > someone does this...
> > >
> > > Does this read "let's pull LTP into the kernel source tree"?
> >
> > Everyone always asks this, and I say, "Sure, why not?"
> >
> > Actually, if people do complain about "why", then let's take the
> > "useful" subset of LTP for kernel developers. It's a great place to
> > start, don't you agree?
This sure seems to be recurring topic. My opinion is that this wouldn't
be huge win.
There are a few downsides to this approach as well:
LTP is backward compatible and it makes sense to use the latest version
even for a few years old kernel/distro, because that brings you more
coverage and fixes. If it was part of the kernel tree there would be a
danger of people using outdated version packed with the kernel sources.
Splitting LTP it into two parts is in my opinion wrong thing to do,
because you will end up with two places that have to share some files
which will impose overhead in maintenance and confusion. Actually I've
looked over the testcases LTP has and it seems that there is a very
little testcases that are not kernel related (there are a few tests for
userspace tools (such as tar, unzip, su, at...) and some network tests).
> Cyril Hrubis is an LTP expert who has spend a considerable amount of time
> cleaning it up but is not often seen in kernel development circles so I added
> him to the cc. He's stated before that there is a large subset of LTP that
> is considerably cleaner than it was a few years ago. Cyril, you are probably
> not subscribed but the list archives for the "kernel testing standard" thread
> can be seen at http://lists.linuxfoundation.org/pipermail/ksummit-discuss/
> if you dig around a bit.
I've read this thread and what it's largely about is integration and
documentation both can be easily done even without pulling LTP into
kernel git tree.
Integrating LTP into 'make test' would be reasonably easy task. You just
need to download latest sources, build them, install and run it, then
look into single file for list of failures.
The more complicated part, as Ted said, is to figure out which tests to
run and on what occasion. For that you have to keep a list of testcases
per a group of interest which is time consuming and prone to error.
> There is a hazard that someone bisecting the tree would need to be careful
> to not bisect LTP instead. Otherwise, in your opinion how feasible
> would it be to import the parts of LTP you trust into the kernel tree
> under tools/testing/ ?
That depends on how closely you want to integrate with the rest of the
source tree. Copying all needed pieces from LTP source there would be
fairly easy.
However as I wrote earlier I want to avoid splitting the LTP source tree
in half. That would overly complicate the way LTP community works now.
What we do, for quite some time now, is to fix/cleanup testcase by
testcase and enable the fixed ones in default testrun.
--
Cyril Hrubis
chrubis@suse.cz
prev parent reply other threads:[~2014-06-05 8:39 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 11:47 Masami Hiramatsu
2014-05-23 13:32 ` Jason Cooper
2014-05-23 16:24 ` Olof Johansson
2014-05-23 16:35 ` Guenter Roeck
2014-05-23 16:36 ` Jason Cooper
2014-05-23 18:10 ` Masami Hiramatsu
2014-05-23 18:36 ` Jason Cooper
2014-05-23 18:06 ` Masami Hiramatsu
2014-05-23 18:32 ` Jason Cooper
2014-05-23 14:05 ` Justin M. Forbes
2014-05-23 16:04 ` Mark Brown
2014-05-24 0:30 ` Theodore Ts'o
2014-05-24 1:15 ` Guenter Roeck
2014-05-26 11:33 ` Masami Hiramatsu
2014-05-30 18:35 ` Steven Rostedt
2014-05-30 20:59 ` Kees Cook
2014-05-30 22:53 ` Theodore Ts'o
2014-06-04 13:51 ` Masami Hiramatsu
2014-05-26 17:08 ` Daniel Vetter
2014-05-26 18:21 ` Mark Brown
2014-05-28 15:37 ` Mel Gorman
2014-05-28 18:57 ` Greg KH
2014-05-30 12:07 ` Linus Walleij
2014-06-05 0:23 ` Greg KH
2014-06-05 6:54 ` Mel Gorman
2014-06-05 8:30 ` Geert Uytterhoeven
2014-06-05 8:44 ` chrubis
2014-06-05 8:53 ` Daniel Vetter
2014-06-05 11:17 ` Masami Hiramatsu
2014-06-05 11:58 ` Daniel Vetter
2014-06-06 9:10 ` Masami Hiramatsu
2014-06-05 14:10 ` James Bottomley
2014-06-06 9:17 ` Masami Hiramatsu
2014-06-09 14:44 ` chrubis
2014-06-09 17:54 ` Michael Kerrisk (man-pages)
2014-06-05 8:39 ` chrubis [this message]
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=20140605083907.GA11139@rei.Home \
--to=chrubis@suse.cz \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=mgorman@suse.de \
/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