From: Kees Cook <keescook@chromium.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "Bird, Tim" <Tim.Bird@sony.com>,
"shuah@kernel.org" <shuah@kernel.org>,
"luto@amacapital.net" <luto@amacapital.net>,
"wad@chromium.org" <wad@chromium.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kernel-team@fb.com" <kernel-team@fb.com>
Subject: Re: [PATCH v2 0/4] kselftest: add fixture parameters
Date: Mon, 16 Mar 2020 14:01:33 -0700 [thread overview]
Message-ID: <202003161356.6CD6783@keescook> (raw)
In-Reply-To: <20200316130416.4ec9103b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Mon, Mar 16, 2020 at 01:04:16PM -0700, Jakub Kicinski wrote:
> Variant sounds good too, although the abbreviation would be VAR?
> Which isn't ideal.
>
> But I really don't care so whoever cares the most please speak up :P
Let's go with "variant" and just spell it out.
> > BTW - Fuego has a similar feature for naming a collection of test
> > parameters with specific values (if I understand this proposed
> > feature correctly). Fuego's feature was named a long time ago
> > (incorrectly, I think) and it continues to bug me to this day.
> > It was named 'specs', and after giving it considerable thought
> > I've been meaning to change it to 'variants'.
> >
> > Just a suggestion for consideration. The fact that Fuego got this
> > wrong is what motivates my suggestion today. You have to live
> > with this kind of stuff a long time. :-)
> >
> > We ran into some issues in Fuego with this concept, that motivate
> > the comments below. I'll use your 'instance' terminology in my comments
> > although the terminology is different in Fuego.
> >
> > > Also a change in reporting:
> > >
> > > struct __fixture_params_metadata no_param = { .name = "", };
> > >
> > > Let's make ".name = NULL" here, and then we can detect instantiation:
> > >
> > > printf("[ RUN ] %s%s%s.%s\n", f->name, p->name ? "." : "",
> > > p->name ?: "", t->name);
>
> Do I have to make it NULL or is it okay to test p->name[0] ?
> That way we can save one ternary operator from the litany..
I did consider Tim's idea of having them all say 'default', but since
the bulk of tests aren't going to have variants, I don't want to spam
the report with words I have to skip over.
And empty-check (instead of NULL) is fine by me.
> To me global.default.XYZ is a mouthful. so in my example (perhaps that
> should have been part of the cover letter) I got:
>
> [ RUN ] global.keysizes <= non-fixture test
> [ OK ] global.keysizes
> [ RUN ] tls_basic.base_base <= fixture: "tls_basic", no params
> [ OK ] tls_basic.base_base
> [ RUN ] tls12.sendfile <= fixture: "tls", param: "12"
> [ OK ] tls12.sendfile
> [ RUN ] tls13.sendfile <= fixture: "tls", param: "13"
> [ OK ] tls13.sendfile (same fixture, diff param)
>
> And users can start inserting underscores themselves if they really
> want. (For TLS I was considering different ciphers but they don't impact
> testing much.)
The reason I'd like a dot is just for lay-person grep-ability and
to avoid everyone needing to remember to add separator prefixes --
there should just be a common one. e.g. searching for "tls13" in the
tree wouldn't find the test (since it's actually named "tls" and "13"
is separate places). (I mean, sure, searching for "tls" is also insane,
but I think I made my point.)
-Kees
--
Kees Cook
next prev parent reply other threads:[~2020-03-16 21:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-14 0:54 [PATCH v2 0/4] kselftest: add fixture parameters Jakub Kicinski
2020-03-14 0:54 ` [PATCH v2 1/4] selftests/seccomp: use correct FIXTURE macro Jakub Kicinski
2020-03-14 0:54 ` [PATCH v2 2/4] kselftest: create fixture objects Jakub Kicinski
2020-03-14 0:55 ` [PATCH v2 3/4] kselftest: add fixture parameters Jakub Kicinski
2020-03-14 0:55 ` [PATCH v2 4/4] selftests: tls: run all tests for TLS 1.2 and TLS 1.3 Jakub Kicinski
2020-03-14 4:41 ` [PATCH v2 0/4] kselftest: add fixture parameters Kees Cook
2020-03-16 15:55 ` Bird, Tim
2020-03-16 20:04 ` Jakub Kicinski
2020-03-16 21:01 ` Kees Cook [this message]
2020-03-16 21:27 ` Jakub Kicinski
2020-03-15 7:05 ` David Miller
2020-03-15 20:55 ` Kees Cook
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=202003161356.6CD6783@keescook \
--to=keescook@chromium.org \
--cc=Tim.Bird@sony.com \
--cc=kernel-team@fb.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=netdev@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=wad@chromium.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).