archive mirror
 help / color / mirror / Atom feed
From: "Bird, Tim" <>
To: Paolo Bonzini <>,
	Shuah Khan <>,
	"" <>,
	"" <>
Cc: "" <>,
	Kees Cook <>
Subject: RE: [PATCH] kselftest: runner: fix TAP output for skipped tests
Date: Mon, 15 Jun 2020 19:28:20 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> -----Original Message-----
> From: Paolo Bonzini <>
> On 10/06/20 19:43, Bird, Tim wrote:
> >>>   		(rc=$?;	\
> >>>   		if [ $rc -eq $skip_rc ]; then	\
> >>> -			echo "not ok $test_num $TEST_HDR_MSG # SKIP"
> >>> +			echo "ok $test_num $TEST_HDR_MSG # SKIP"
> >
> > This is a pretty big change, and might break upstream CIs that have come to
> > rely on kselftest's existing behavior.  I know it's going to break Fuego's parsing
> > of results.
> Do you have a pointer to this code?
> > kselftest has a few conventions that are different from the TAP spec,
> > and a few items it does that are extensions to the TAP spec.
> Yes, there are extensions to directives are not a problem and parsers
> might raise an error on them.  That can be an issue, but it's a separate
> one (and it's easier to ignore it as long as test pass...).
> > IMHO, the TAP spec got this one wrong, but I could be convinced
> > otherwise.
> Here the TAP spec says that a skip starts with "ok" and has a "SKIP"
> directive, and anyone can parse it to treat as it as a failure if
> desirable.  But doing something else should be treated simply as a
> violation of the spec, it's not a matter of "right" or "wrong".
> So, if you want to use "not ok ... # SKIP", don't call it TAP.

Well, for some time now I've been in favor of us calling the
kernel tests' format "KTAP".
But I agree if there are no strong reasons to be different we should
have the same convention as TAP 13.

I looked at Fuego, and it's trivial to change it's parser (and I've wanted
to consolidate the kselftest parser with other TAP parsers in Fuego,
so it's probably best for Fuego to go with the SKIP="ok" convention anyway.)
I haven't released an updated kselftest for Fuego in a while, so I
don't think many of Fuego's users will be affected if I switch.  Plus
I know most of them so I can smooth it over if it's a problem.  SKIP 
really should be treated differently than "ok" or "not ok" anyway.

I raised this issue on our automated testing conference call last week.
The call had people from the KernelCI, CKI, LKFT and Fuego projects,
so at least those projects have gotten the word and have a chance to
object if this will affect their results parsers.

> However, I noticed now that there is another instance of "not ok.*SKIP"
> in testing/selftests/kselftest.h (and also one in a comment).  So they
> should all be fixed at the same time, and I'm okay with holding this patch.

Agree that we should change it everywhere once we decide.  Nice catch.

For my part, I'm OK with moving to the "SKIP=ok" convention (in agreement
with TAP13).  I don't know if we need to wait longer for others to have a chance
to review this or not, but maybe wait a few days and then go for it?
 -- Tim

> Paolo
> > But I think we should discuss this among CI users of
> > kselftest before making the change.
> >
> > I started work quite a while ago on an effort to document the
> > conventions used by kselftest (particularly where it deviates
> > from the TAP spec),  but never submitted it.
> >
> > I'm going to submit what I've got as an RFC now, for discussion,
> > even though it's not finished.  I'll do that in a separate thread.
> >
> >
> >>>   		elif [ $rc -eq $timeout_rc ]; then \
> >>>   			echo "#"
> >>>   			echo "not ok $test_num $TEST_HDR_MSG # TIMEOUT"
> >>>
> >>
> >> Thanks. I will pull this in for Linux 5.8-rc2
> > Shuah - can you hold off on this until we discuss it?
> >
> > Thanks,
> >  -- Tim
> >

  reply	other threads:[~2020-06-15 19:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10 15:44 Paolo Bonzini
2020-06-10 16:19 ` Shuah Khan
2020-06-10 17:43   ` Bird, Tim
2020-06-10 18:22     ` Paolo Bonzini
2020-06-15 19:28       ` Bird, Tim [this message]
2020-06-10 20:02     ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='RE: [PATCH] kselftest: runner: fix TAP output for skipped tests' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).