linux-kernel - Re: [PATCH 1/1] of: unittest: print pass messages at same loglevel as fail

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]

Date:   Wed, 9 Feb 2022 18:34:49 -0600
From:   Rob Herring <robh@...nel.org>
To:     Frank Rowand <frowand.list@...il.com>
Cc:     Naresh Kamboju <naresh.kamboju@...aro.org>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Anders Roxell <anders.roxell@...aro.org>,
        devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] of: unittest: print pass messages at same loglevel
 as fail

On Thu, Feb 03, 2022 at 09:41:45PM -0600, Frank Rowand wrote:
> On 2/3/22 3:40 PM, Rob Herring wrote:
> > On Thu, Feb 3, 2022 at 3:12 PM <frowand.list@...il.com> wrote:
> >>
> >> From: Frank Rowand <frank.rowand@...y.com>
> >>
> >> Printing the devicetree unittest pass message for each passed test
> >> creates much console verbosity.  The existing pass messages are
> >> printed at loglevel KERN_DEBUG so they will not print by default.
> >>
> >> Change default to print the pass messages at the same loglevel as
> >> the fail messages.
> >>
> >> The test community expects either a pass or a fail message for each
> >> test in a test suite.  The messages are typically post-processed to
> >> report pass/fail results.
> >>
> >> Suppressing printing the pass message for each individual test is
> >> available via the kernel command line parameter unittest.hide_pass.
> >>
> >> Signed-off-by: Frank Rowand <frank.rowand@...y.com>
> >> ---
> >>  Documentation/admin-guide/kernel-parameters.txt |  4 ++++
> >>  drivers/of/unittest.c                           | 17 ++++++++++++++++-
> >>  2 files changed, 20 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> >> index f5a27f067db9..045455f9b7e1 100644
> >> --- a/Documentation/admin-guide/kernel-parameters.txt
> >> +++ b/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -5997,6 +5997,10 @@
> >>                         Note that genuine overcurrent events won't be
> >>                         reported either.
> >>
> >> +       unittest.hide_pass
> > 
> > Can we rename the module name to include 'dt' so we're not taking a
> > generic name.
> 
> I got most of the way through writing a reply to the various questions, then got to
> the point where my answer to a specific question ended up being something to the
> effect of: "this line of code (where a change was suggested) will end up being
> replaced when I convert the unittest messages to KTAP format".
> 
> Then I got sidelined by going back and re-reading the KTAP specification email
> thread from August, then discovering that there is also a patch submission email
> thread from December where a KTAP specification is accepted into the kernel tree.
> 
> Being KTAP compliant does not allow for suppressing the individual test pass
> messages, so I think I should just drop my desire to be able to do so.  That
> would reduce this patch to a one line change to print the pass messages at the
> same loglevel as the fail messages.  And I would prefer to not worry about
> whether the pass message is 'pass' vs 'PASS' since that text will get replaced
> by the KTAP syntax anyway.
> 
> Would you be ok with that one line patch?

At info level, yes. If not, how soon until using ktap syntax?

Rob