From: Michael Ellerman <mpe@ellerman.id.au>
To: Brian Norris <computersforpeace@gmail.com>,
Shuah Khan <shuahkh@osg.samsung.com>
Cc: linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
Kees Cook <keescook@chromium.org>
Subject: Re: [RFC] selftests: report proper exit statuses
Date: Mon, 14 Dec 2015 14:19:35 +1100 [thread overview]
Message-ID: <1450063175.29082.2.camel@ellerman.id.au> (raw)
In-Reply-To: <1449875706-106875-1-git-send-email-computersforpeace@gmail.com>
Hi Brian,
On Fri, 2015-12-11 at 15:15 -0800, Brian Norris wrote:
> There are several places where we don't report proper exit statuses, and
> this can have consequences -- for instance, the gen_kselftest_tar.sh
> script might try to produce a tarball for you, even if the 'make' or
> 'make install' steps didn't complete properly.
>
> This is only an RFC (and really, it's more like a bug report), since I'm
> not really satisfied with my solution.
The changes to the tar script are probably OK.
But in general we do not want to exit after the first failure, which is what
your changes to the for loops would do.
The intention is to build and run as many tests as possible, on as many
architectures and machines as possible. So stopping the build because a header
or library is missing, or stopping the test run because one test fails, is the
exact opposite of what we want to happen.
For example a test might fail because it was written for x86 and doesn't work
on powerpc, if that caused all my powerpc tests to not run, I would be very
unpleased.
> It's probably not exhaustive, and
> there seem to be some major other deficiencies (e.g., verbose/useless
> output during build and run, non-paralle build, shell for-loops sidestep
> some normal 'make' behavior).
The goals for the kernel selftests are to make it as easy as possible to merge
tests, so that as many developers as possible create tests *and* merge them.
The current scheme supports that by not imposing much in the way of build
system requirements, or standards on what is or isn't appropriate output etc.
But if have ideas for improving things while still keeping the requirements on
test code low then I'm all ears.
cheers
next prev parent reply other threads:[~2015-12-14 3:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-11 23:15 [RFC] selftests: report proper exit statuses Brian Norris
2015-12-14 3:19 ` Michael Ellerman [this message]
2015-12-14 19:15 ` Brian Norris
2015-12-17 9:26 ` Michael Ellerman
2015-12-28 16:47 ` Shuah Khan
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=1450063175.29082.2.camel@ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=computersforpeace@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shuahkh@osg.samsung.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