linux-kernel - Re: RFC - kernel selftest result documentation (KTAP)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFd5g458XTDftQAOm-K4Squ5-ZuZnZcFdVUG0JtUWF56cODOVg@mail.gmail.com>
Date:   Tue, 16 Jun 2020 13:03:48 -0700
From:   Brendan Higgins <brendanhiggins@...gle.com>
To:     "Bird, Tim" <Tim.Bird@...y.com>
Cc:     David Gow <davidgow@...gle.com>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: RFC - kernel selftest result documentation (KTAP)

On Mon, Jun 15, 2020 at 10:34 AM Bird, Tim <Tim.Bird@...y.com> wrote:
>
> > -----Original Message-----
> > From: David Gow <davidgow@...gle.com>
> >
> > On Thu, Jun 11, 2020 at 2:11 AM Bird, Tim <Tim.Bird@...y.com> wrote:
[...]
> > KUnit is currently outputting "TAP version 14", as we were hoping some
> > of our changes would get into the TAP14 spec. (Any comments, Brendan?)
> > Maybe this should end up saying "KTAP version 1" or something?
>
> I don't know if this will break any existing results parsers or not.
> I hesitate to use "TAP version 14", as TAP appears to be a dormant
> initiative at the moment, and there's no guarantee that the kernel's
> changes will get adopted into an official spec.

We were using "TAP version 14" since the "extensions" we are using
were all proposed among the TAP people to go into the next version of
TAP. Based on discussions among them they seem to like the subtest
stuff:

https://github.com/TestAnything/testanything.github.io/pull/36

Anyway, I can still appreciate that they might change their minds.

> If we are a strict super-set of TAP, then I suppose we could just
> start using TAP version 14, and unilaterally declare that our changes
> make a new spec.  But since we don't control the web site this feels
> like a hostile takeover.

I just thought it was okay because it was already in their proposed
TAP14 spec, but yeah, if we just decide amongst ourselves to use it,
we should probably do something else.

> I'm most comfortable with calling our thing KTAP, and just
> referencing TAP as inspiration.  I don't have a strong opinion on

I am cool with that.

> KTAP vs TAP, but I do feel strongly that kselftest and kunit should use the
> same version line (if we can get them to use the same conventions).

Yeah, I agree: it would be better if there was just one version of
(K)TAP in the kernel.

> > > Test plan line
> > > --------------
> > > The test plan indicates the number of individual test cases intended to
> > > be executed by the test. It always starts with "1.." and is followed
> > > by the number of tests cases.  In the example above, 1..1", indicates
> > > that this test reports only 1 test case.
> > >
> > > The test plan line can be placed in two locations:
> > >  * the second line of test output, when the number of test cases is known
> > >    in advance
> > >  * as the last line of test output, when the number of test cases is not
> > >    known in advance.
> > >
> > > Most often, the number of test cases is known in advance, and the test plan
> > > line appears as the second line of test output, immediately following
> > > the output version line.  The number of test cases might not be known
> > > in advance if the number of tests is calculated from runtime data.
> > > In this case, the test plan line is emitted as the last line of test
> > > output.
> >
> > KUnit is currently including the test plan line only for subtests, as
> > the current version doesn't actually know how many test suites will
> > run in advance.
> > This is something there's work underway to fix, though.
> Sounds good.  You can just put the line at the bottom if it's
> obnoxious to calculate ahead of time.

I thought that is not in the TAP spec?

I kind of like printing out ahead of time how many tests we expect to
run, so if we crash we know how many tests weren't run.

In any case, until we get the change in that David is referencing, we
cannot print out the test plan for the "super test" before or after
because KUnit doesn't know when it is "done". So moving it to the
bottom doesn't really help us.

> Does this mean that KUnit treats each sub-test as an individual test case
> of the "super-test"?

Yes.

At the top level, we have all test suites. Each subtest in TAP is a
test suite in KUnit. Each case in each subtest in TAP is a test case
in KUnit.

> In results summaries for a super-test, are all sub-test cases counted,
> or just the list of sub-tests?

Just the sub-tests. Each subtest is responsible for counting it's own cases:

https://github.com/isaacs/testanything.github.io/blob/tap14/tap-version-14-specification.md#subtests

Cheers