linux-kernel - Re: [PATCH 2/4] kunit: rename base KUNIT_ASSERTION macro to _KUNIT

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:   Fri, 30 Sep 2022 20:50:40 -0700
From:   Daniel Latypov <dlatypov@...gle.com>
To:     David Gow <davidgow@...gle.com>
Cc:     Brendan Higgins <brendanhiggins@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        KUnit Development <kunit-dev@...glegroups.com>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Subject: Re: [PATCH 2/4] kunit: rename base KUNIT_ASSERTION macro to _KUNIT_FAILED

On Fri, Sep 30, 2022 at 8:26 PM David Gow <davidgow@...gle.com> wrote:
>
> On Sat, Oct 1, 2022 at 8:26 AM 'Daniel Latypov' via KUnit Development
> <kunit-dev@...glegroups.com> wrote:
> >
> > Context:
> > Currently this macro's name, KUNIT_ASSERTION conflicts with the name of
> > an enum whose values are {KUNIT_EXPECTATION, KUNIT_ASSERTION}.
> >
> > It's hard to think of a better name for the enum, so rename this macro.
> > It's also a bit strange that the macro might do nothing depending on the
> > boolean argument `pass`. Why not have callers check themselves?
> >
> > This patch:
> > Moves the pass/fail checking into the callers of KUNIT_ASSERTION, so now
> > we only call it when the check has failed.
> > Then we rename the macro the _KUNIT_FAILED() to reflect the new
> > semantics.
> >
> > Signed-off-by: Daniel Latypov <dlatypov@...gle.com>
> > ---
>
> Looks good to me. I can't say the name _KUNIT_FAILED() feels perfect
> to me, but I can't think of anything better, either. We've not used a
> leading underscore for internal macros much thus far, as well, though
> I've no personal objections to starting.

Yeah, I also didn't add a leading underscore on the new
KUNIT_INIT_ASSERT() macro elsewhere in this series.
So I'm not necessarily proposing that we should start doing so here.

It feels like that KUNIT_FAILED is far too similar to the enum
    55 enum kunit_status {
    56         KUNIT_SUCCESS,
    57         KUNIT_FAILURE,
    58         KUNIT_SKIPPED,
    59 };

I.e. we'd be remove one naming conflict between a macro and enum, but
basically introducing a new one in its place :P
Tbh, I was originally going to have this patch just be
s/KUNIT_ASSERTION()/_KUNIT_ASSERTION() to reduce the conflict.
But I figured we could reduce the number of arguments to the macro
(drop `pass`) and have a reason to give it a different name.

I'm also not entirely convinced about _KUNIT_FAILED(), but I haven't
had any significantly better ideas since I sent the RFC in May.

Daniel