All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.