From: Daniel Latypov <dlatypov@google.com>
To: David Gow <davidgow@google.com>
Cc: Brendan Higgins <brendanhiggins@google.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
KUnit Development <kunit-dev@googlegroups.com>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Subject: Re: [PATCH 2/4] kunit: rename base KUNIT_ASSERTION macro to _KUNIT_FAILED
Date: Fri, 30 Sep 2022 20:50:40 -0700 [thread overview]
Message-ID: <CAGS_qxpDdAz6DZxojhnh_XRuJ4MR-oQkQNCES_Lpe1OEO8QTUQ@mail.gmail.com> (raw)
In-Reply-To: <CABVgOSn3SupF_z84FghxX-yK-CLx_RQMkUxF_hGUw6a3w7h-7Q@mail.gmail.com>
On Fri, Sep 30, 2022 at 8:26 PM David Gow <davidgow@google.com> wrote:
>
> On Sat, Oct 1, 2022 at 8:26 AM 'Daniel Latypov' via KUnit Development
> <kunit-dev@googlegroups.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@google.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
next prev parent reply other threads:[~2022-10-01 3:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-01 0:26 [PATCH 0/4] kunit: more assertion reworking Daniel Latypov
2022-10-01 0:26 ` [PATCH 1/4] kunit: remove format func from struct kunit_assert, get it to 0 bytes Daniel Latypov
2022-10-01 3:26 ` David Gow
2022-10-01 0:26 ` [PATCH 2/4] kunit: rename base KUNIT_ASSERTION macro to _KUNIT_FAILED Daniel Latypov
2022-10-01 3:26 ` David Gow
2022-10-01 3:50 ` Daniel Latypov [this message]
2022-10-01 4:13 ` David Gow
2022-10-01 0:26 ` [PATCH 3/4] kunit: eliminate KUNIT_INIT_*_ASSERT_STRUCT macros Daniel Latypov
2022-10-01 3:26 ` David Gow
2022-10-01 10:12 ` Miguel Ojeda
2022-10-01 17:48 ` Daniel Latypov
2022-10-01 0:26 ` [PATCH 4/4] kunit: declare kunit_assert structs as const Daniel Latypov
2022-10-01 3:26 ` David Gow
2022-10-01 10:06 ` Miguel Ojeda
2022-10-01 10:15 ` [PATCH 0/4] kunit: more assertion reworking Miguel Ojeda
2022-10-01 18:00 ` Daniel Latypov
2022-10-18 23:20 ` Miguel Ojeda
2022-10-18 23:26 ` Daniel Latypov
2022-10-18 23:39 ` Miguel Ojeda
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=CAGS_qxpDdAz6DZxojhnh_XRuJ4MR-oQkQNCES_Lpe1OEO8QTUQ@mail.gmail.com \
--to=dlatypov@google.com \
--cc=brendanhiggins@google.com \
--cc=davidgow@google.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=skhan@linuxfoundation.org \
/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;
as well as URLs for NNTP newsgroup(s).