linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Brendan Higgins <brendanhiggins@google.com>
Cc: "Bird, Tim" <Tim.Bird@sony.com>,
	"shuah@kernel.org" <shuah@kernel.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Gow <davidgow@google.com>,
	Frank Rowand <frowand.list@gmail.com>
Subject: Re: RFC - kernel selftest result documentation (KTAP)
Date: Sat, 20 Jun 2020 09:51:06 -0500	[thread overview]
Message-ID: <8b31b4b4-2b26-65f3-1026-cdc62cc710cd@gmail.com> (raw)
In-Reply-To: <c60c25ab-6737-1cc9-4370-dae4ebb4b823@redhat.com>

On 2020-06-19 17:58, Paolo Bonzini wrote:
> On 19/06/20 20:47, Frank Rowand wrote:
>> Or if the entire test depends on the missing config then Bail out might
>> be appropriate.
> 
> No, in that case you want
> 
> 	1..0 # SKIP: unsupported configuration
> 
> The spec is not clear if "Bail out!" is an error condition or just a
> warning that only part of the test was run, but prove(1) and Automake
> both treat it as the former, for example.
> 
> For example, an ENOSPC error creating a temporary file could be turned
> into a bail-out, while an ENOSYS would be a skip.
> 
> Paolo
> 

I think that "Bail out!" needs to be more clearly defined by the spec,
and we should come up with an intent of what it is intended to mean.

The TAP 13 spec gives a "Bail out!" example of "MySQL is not running."
The spec gives this example after the general guidance of (among other
things) "missing dependencies".  A missing config _could_ be thought
of as a missing dependency.

To me, the key differentiator for "Bail out!" is "that further tests
are useless".  In other words, the detected problem means that
every subsequent part of the tests will fail for the same reason.

If _some_ subsequent parts of the tests will NOT fail for the same
reason then SKIP becomes more reasonable.  What percent of subsequent
parts of the tests is large enough to comprise "_some_" is probably
a value judgement.

For the case that I was commenting on, with the limited amount of
description provided, my preference is also SKIP, which is what I
was suggesting.

  reply	other threads:[~2020-06-20 14:51 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10 18:11 RFC - kernel selftest result documentation (KTAP) Bird, Tim
2020-06-13  5:07 ` David Gow
2020-06-15 17:34   ` Bird, Tim
2020-06-16 20:03     ` Brendan Higgins
2020-06-16 20:37       ` Bird, Tim
2020-06-17  0:02         ` Kees Cook
2020-06-19 19:32         ` Brendan Higgins
2020-06-19 18:17       ` Frank Rowand
2020-06-14 18:17 ` Kees Cook
2020-06-15 17:45   ` Bird, Tim
2020-06-15 18:44     ` Kees Cook
2020-06-14 18:39 ` Kees Cook
2020-06-15 19:07   ` Bird, Tim
2020-06-16 12:08     ` Paolo Bonzini
2020-06-16 16:42       ` Bird, Tim
2020-06-16 19:44         ` Brendan Higgins
2020-06-16 20:30           ` Bird, Tim
2020-06-16 23:58           ` Kees Cook
2020-06-19 18:47             ` Frank Rowand
2020-06-19 19:11               ` Kees Cook
2020-06-19 22:58               ` Paolo Bonzini
2020-06-20 14:51                 ` Frank Rowand [this message]
2020-06-19 18:33         ` Frank Rowand
2020-06-19 17:58       ` Frank Rowand
2020-06-20  6:44         ` David Gow
2020-06-20 15:03           ` Frank Rowand
2020-06-23  2:58             ` David Gow
2020-06-16 23:52     ` Kees Cook
2020-06-19 18:52       ` Frank Rowand
2020-06-19 19:50       ` Brendan Higgins
2020-06-19 19:49     ` Frank Rowand
2020-06-16 20:48 ` Brendan Higgins
2020-06-16 21:16   ` Bird, Tim
2020-06-16 21:19     ` Bird, Tim
2020-06-17  0:06     ` Kees Cook
2020-06-17  2:30       ` Bird, Tim
2020-06-17  3:36         ` Kees Cook
2020-06-17  4:05           ` David Gow
2020-06-19 19:44             ` Brendan Higgins
2020-06-19 20:19             ` Frank Rowand
2020-06-19 23:47               ` Bird, Tim
2020-06-19 19:39     ` Brendan Higgins
2020-06-19 17:13 ` Frank Rowand

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=8b31b4b4-2b26-65f3-1026-cdc62cc710cd@gmail.com \
    --to=frowand.list@gmail.com \
    --cc=Tim.Bird@sony.com \
    --cc=brendanhiggins@google.com \
    --cc=davidgow@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=shuah@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).