Re: kselftest: Bad test result: from results parsing in LAVA

[Mark Brown]

On Wed, Nov 16, 2022 at 07:36:10PM +0530, Naresh Kamboju wrote:
> On Wed, 16 Nov 2022 at 18:57, Mark Brown <broonie@xxxxxxxxxx> wrote:
> > On Wed, Nov 16, 2022 at 05:46:33PM +0530, Naresh Kamboju wrote:

> > > Test results parser showing “Bad test results: “,

> > When reporting an issue can you please try to provide some
> > analysis which goes beyond the level of "I saw an error message"
> > - for example here it's hard to tell if you think you're seeing
> > an issue somewhere in your test automation system or if you're
> > trying to report something in the tests.

> Let me add more information about this,

> Kees Cook, has done the work of a kselftest results parser in perl
> which is in the test-definitions repository. which was working well
> for two years now. please refer to the below commit log and link to
> the kselftest test-definitions [3].

> The new test cases output is not coping up with the old results parser
> and both KernelCI [1] and LKFT [2] using LAVA have noticed.
> Kselftest results parser problem [4].

I'm still not clear if you believe there is an issue in the tests
or in your test infrastructure here.  I can't identify any
problem with the test output, everything appears to be within the
KTAP spec:

   https://www.kernel.org/doc/html/latest/dev-tools/ktap.html#test-case-result-lines

My best guess is that either this script which the infrastructure
is using or something else that uses the results of the script is
broken when the test description includes spaces.  The KTAP spec
says that each test case result is a line in the form:

   <result> <number> [<description>][ # [<directive>] [<diagnostic data>]]

where

   The description is a description of the test, generally the
   name of the test, and can be any string of words (can’t include #).
   The description is optional, but recommended.

ie, anything after the space following the test number up to a #
or the end of the line is a valid test description (it's not the
intent but it does appear that the # needs to have a space before
it).  You could argue that non-alphabetic characters are out of
spec for the description since any separators between words
aren't themselves words but realistically that'd invalidate a
fairly large subset of the selftests which probably isn't
constructive.

Attachment: signature.asc
Description: PGP signature