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
| ||
|
Message-ID: <3a4ed4a0-5694-ba59-a141-26e37576ff67@gmail.com> Date: Sun, 26 Mar 2023 21:44:30 -0500 From: Frank Rowand <frowand.list@...il.com> To: Daniel Latypov <dlatypov@...gle.com>, Rae Moar <rmoar@...gle.com> Cc: davidgow@...gle.com, skhan@...uxfoundation.org, keescook@...omium.org, Tim.Bird@...y.com, brendanhiggins@...gle.com, corbet@....net, guillaume.tucker@...labora.com, kernelci@...ts.linux.dev, kunit-dev@...glegroups.com, linux-kselftest@...r.kernel.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [KTAP V2 PATCH] ktap_v2: add recognized test name line On 3/20/23 14:21, Daniel Latypov wrote: > On Thu, Mar 16, 2023 at 3:59 PM Rae Moar <rmoar@...gle.com> wrote: >> >> Add recognition of the test name line ("# Subtest: <name>") to the KTAP v2 >> spec. >> >> The purpose of this line is to declare the name of a test before its >> results. This functionality is especially useful when trying to parse test >> results incrementally and when interpretting results after a crash. >> >> This line is already compliant with KTAP v1 as it is interpretted as a > > minor nit for if there's a v2, s/interprett/interpret (here and above) > > Also, I want to elaborate on the previous paragraph a bit more, in > case the motivation isn't clear. > The problem with TAP and KTAP as-is is that the name of a test case is > only known *after* it completes. > > So the scenario being referred to is > > KTAP version 1 > 1..1 > <lots of output> > <kernel crash, no more output> > > It would be nice if parsers could report "test FOO caused a crash" as > opposed to "the first test case caused a crash, good luck figuring out > which one that was" > > Daniel It would be useful to take some of the motivation explanation from TAP14, which says (everything to the end of this email): Commented Subtests are encouraged, as they provide the following benefits: Easier for humans to read. For example: TAP version 14 1..1 ok 1 - hmm, what level is this? vs: TAP version 14 # Subtest: level 1 # Subtest: level 2 # Subtest: level 3 1..1 ok 1 - clearly level 3 Additional strictness around matching the Test Point description to Subtest Name can catch errors and detect accidentally interleaved output.
Powered by blists - more mailing lists