public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Tamir Duberstein <tamird@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	David Gow <davidgow@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Shuah Khan <shuah@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v7 0/3] scanf: convert self-test to KUnit
Date: Fri, 14 Feb 2025 14:33:32 +0100	[thread overview]
Message-ID: <Z69GLMVPCuKKz1gk@pathway.suse.cz> (raw)
In-Reply-To: <CAJ-ks9k9d4aX+P9F10h3TqHPOCHEQ5m=QyMAv7bU+Xyb3LRsOQ@mail.gmail.com>

On Wed 2025-02-12 11:54:52, Tamir Duberstein wrote:
> On Tue, Feb 11, 2025 at 12:26 PM Tamir Duberstein <tamird@gmail.com> wrote:
> >
> > > Is it me who cut something or the above missing this information (total tests)?
> > > If the latter, how are we supposed to answer to the question if the failed test
> > > is from new bunch of cases I hypothetically added or regression of the existing
> > > ones? Without this it seems like I need to go through all failures. OTOH it may
> > > be needed anyway as failing test case needs an investigation.
> >
> > I assume you mean missing from the new output. Yeah, KUnit doesn't do
> > this counting. Instead you get the test name in the failure message:
> >
> > > > > > > >     vsscanf("0 1e 3e43 31f0 0 0 5797 9c70", "%1hx %2hx %4hx %4hx %1hx %1hx %4hx %4hx", ...) expected 837828163 got 1044578334
> > > > > > > >             not ok 1 " "
> > > > > > > >         # numbers_list_field_width_val_width: ASSERTION FAILED at lib/scanf_kunit.c:92
> >
> > I think maybe you're saying: what if I add a new assertion (rather
> > than a new test case), and I start getting failure reports - how do I
> > know if the reporter is running old or new test code?
> >
> > In an ideal world the message above would give you all the information
> > you need by including the line number from the test. This doesn't
> > quite work out in this case because of the various test helper
> > functions; you end up with a line number in the test helper rather
> > than in the test itself. We could fix that by passing around __FILE__
> > and __LINE__ (probably by wrapping the test helpers in a macro). What
> > do you think?

I am not sure how many changes are needed to wrap the test helpers in
a macro.

> I gave this a try locally, and it produced this output:
> 
> >     # numbers_list_field_width_val_width: ASSERTION FAILED at lib/scanf_kunit.c:94
> > lib/scanf_kunit.c:555: vsscanf("0 1e 3e43 31f0 0 0 5797 9c70", "%1hx %2hx %4hx %4hx %1hx %1hx %4hx %4hx", ...) expected 837828163 got 1044578334
> >         not ok 1 " "
> >     # numbers_list_field_width_val_width: ASSERTION FAILED at lib/scanf_kunit.c:94
> > lib/scanf_kunit.c:555: vsscanf("dc2:1c:0:3531:2621:5172:1:7", "%3hx:%2hx:%1hx:%4hx:%4hx:%4hx:%1hx:%1hx", ...) expected 892403712 got 28
> >         not ok 2 ":"
> >     # numbers_list_field_width_val_width: ASSERTION FAILED at lib/scanf_kunit.c:94
> > lib/scanf_kunit.c:555: vsscanf("e083,8f6e,b,70ca,1,1,aab1,10e4", "%4hx,%4hx,%1hx,%4hx,%1hx,%1hx,%4hx,%4hx", ...) expected 1892286475 got 757614
> >         not ok 3 ","
> >     # numbers_list_field_width_val_width: ASSERTION FAILED at lib/scanf_kunit.c:94
> > lib/scanf_kunit.c:555: vsscanf("2e72-8435-1-2fc-7cbd-c2f1-7158-2b41", "%4hx-%4hx-%1hx-%3hx-%4hx-%4hx-%4hx-%4hx", ...) expected 50069505 got 99381
> >         not ok 4 "-"
> >     # numbers_list_field_width_val_width: ASSERTION FAILED at lib/scanf_kunit.c:94
> > lib/scanf_kunit.c:555: vsscanf("403/0/17/1/11e7/1/1fe8/34ba", "%3hx/%1hx/%2hx/%1hx/%4hx/%1hx/%4hx/%4hx", ...) expected 65559 got 1507328
> >         not ok 5 "/"

But I really like that the error message shows the exact line of the
caller. IMHO, it is very helpful in this module. I like it.

IMHO, it also justifies removing the pr_debug() messages (currently 1st patch).

> Andy, Petr: what do you think? I've added this (and the original
> output, as you requested) to the cover letter for when I reroll v8
> (not before next week).

I suggest, to do the switch into macros in the 1st patch.
Remove the obsolete pr_debug() lines in 2nd patch.
Plus two more patches switching the module to kunit test.

I am personally fine with this change.

Best Regards,
Petr

  reply	other threads:[~2025-02-14 13:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-11 15:13 [PATCH v7 0/3] scanf: convert self-test to KUnit Tamir Duberstein
2025-02-11 15:13 ` [PATCH v7 1/3] scanf: remove redundant debug logs Tamir Duberstein
2025-02-11 15:42   ` Andy Shevchenko
2025-02-11 15:50     ` Tamir Duberstein
2025-02-11 15:58       ` Andy Shevchenko
2025-02-11 16:02         ` Tamir Duberstein
2025-02-11 17:15           ` Andy Shevchenko
2025-02-11 17:50             ` Tamir Duberstein
2025-02-11 15:13 ` [PATCH v7 2/3] scanf: convert self-test to KUnit Tamir Duberstein
2025-02-11 15:13 ` [PATCH v7 3/3] scanf: break kunit into test cases Tamir Duberstein
2025-02-11 15:40 ` [PATCH v7 0/3] scanf: convert self-test to KUnit Andy Shevchenko
2025-02-11 15:47   ` Tamir Duberstein
2025-02-11 15:54     ` Andy Shevchenko
2025-02-11 15:57       ` Tamir Duberstein
2025-02-11 17:17         ` Andy Shevchenko
2025-02-11 17:26           ` Tamir Duberstein
2025-02-12 16:54             ` Tamir Duberstein
2025-02-14 13:33               ` Petr Mladek [this message]
2025-02-14 15:39                 ` Tamir Duberstein

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=Z69GLMVPCuKKz1gk@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=davidgow@google.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=shuah@kernel.org \
    --cc=tamird@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox