All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gow <davidgow@google.com>
To: Frank Rowand <frowand.list@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"Bird, Tim" <Tim.Bird@sony.com>,
	Kees Cook <keescook@chromium.org>,
	"shuah@kernel.org" <shuah@kernel.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	Brendan Higgins <brendanhiggins@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: RFC - kernel selftest result documentation (KTAP)
Date: Sat, 20 Jun 2020 14:44:56 +0800	[thread overview]
Message-ID: <CABVgOS=qSMY9xP7db4-hkSt71YKyPpJuQv=fqcfzV-kCC1k9qQ@mail.gmail.com> (raw)
In-Reply-To: <dc853d83-649e-b652-819f-4766ea294d78@gmail.com>

On Sat, Jun 20, 2020 at 1:58 AM Frank Rowand <frowand.list@gmail.com> wrote:
>
> On 2020-06-16 07:08, Paolo Bonzini wrote:
> > On 15/06/20 21:07, Bird, Tim wrote:

> >>>> Finally,
> >>>>   - Should a SKIP result be 'ok' (TAP13 spec) or 'not ok' (current kselftest practice)?
> >>>> See https://testanything.org/tap-version-13-specification.html
> >>>
> >>> Oh! I totally missed this. Uhm. I think "not ok" makes sense to me "it
> >>> did not run successfully". ... but ... Uhhh ... how do XFAIL and SKIP
> >>> relate? Neither SKIP nor XFAIL count toward failure, though, so both
> >>> should be "ok"? I guess we should change it to "ok".
> >
> > See above for XFAIL.
> >
> > I initially raised the issue with "SKIP" because I have a lot of tests
> > that depend on hardware availability---for example, a test that does not
> > run on some processor kinds (e.g. on AMD, or old Intel)---and for those
> > SKIP should be considered a success.
>
> No, SKIP should not be considered a success.  It should also not be considered
> a failure.  Please do not blur the lines between success, failure, and
> skipped.

I agree that skipped tests should be their own thing, separate from
success and failure, but the way they tend to behave tends to be
closer to a success than a failure.

I guess the important note here is that a suite of tests, some of
which are SKIPped, can be listed as having passed, so long as none of
them failed. So, the rule for "bubbling up" test results is that any
failures cause the parent to fail, the parent is marked as skipped if
_all_ subtests are skipped, and otherwise is marked as having
succeeded. (Reversing the last part: having a suite be marked as
skipped if _any_ of the subtests are skipped also makes sense, and has
its advantages, but anecdotally seems less common in other systems.)

The other really brave thing one could do to break from the TAP
specification would be to add a "skipped" value alongside "ok" and
"not ok", and get rid of the whole "SKIP" directive/comment stuff.
Possibly not worth the departure from the spec, but it would sidestep
part of the problem.


Cheers,
-- David

  reply	other threads:[~2020-06-20  6:45 UTC|newest]

Thread overview: 46+ 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-14 18:17   ` [Linux-kernel-mentees] " Kees Cook
2020-06-15 17:45   ` Bird, Tim
2020-06-15 17:45     ` [Linux-kernel-mentees] " Bird, Tim
2020-06-15 18:44     ` Kees Cook
2020-06-15 18:44       ` [Linux-kernel-mentees] " 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
2020-06-19 18:33         ` Frank Rowand
2020-06-19 17:58       ` Frank Rowand
2020-06-20  6:44         ` David Gow [this message]
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='CABVgOS=qSMY9xP7db4-hkSt71YKyPpJuQv=fqcfzV-kCC1k9qQ@mail.gmail.com' \
    --to=davidgow@google.com \
    --cc=Tim.Bird@sony.com \
    --cc=brendanhiggins@google.com \
    --cc=frowand.list@gmail.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 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.