All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org,
	daniel@iogearbox.net, kernel-team@fb.com, yhs@fb.com
Subject: Re: [RFC bpf-next 3/5] selftests/bpf: generate boilerplate code for test_loader-based tests
Date: Fri, 27 Jan 2023 01:29:42 +0200	[thread overview]
Message-ID: <aff79e80ef4ae0751f82de42b761b6f27355db1a.camel@gmail.com> (raw)
In-Reply-To: <CAEf4BzaKe3HMmYKvYKarcb7SKvd2Uurd22U5tLjE0RyNMgpSAg@mail.gmail.com>

On Wed, 2023-01-25 at 17:43 -0800, Andrii Nakryiko wrote:
> On Mon, Jan 23, 2023 at 6:52 AM Eduard Zingerman <eddyz87@gmail.com> wrote:
> > 
> > Automatically generate boilerplate code necessary to run tests that
> > use test_loader.c.
> > 
> > Adds a target 'prog_tests/test_loader_auto_wrappers.c' as part of
> > rulesets for 'test_progs' and 'test_progs-no_alu32'. The content of
> > this C file is generated by make and has the following structure:
> > 
> >   #include <test_progs.h>
> > 
> >   #include "some_test_1.skel.h"
> >   #include "some_test_2.skel.h"
> >   ...
> > 
> >   void test_some_test_1(void) { RUN_TESTS(some_test_1); }
> >   void test_some_test_2(void) { RUN_TESTS(some_test_2); }
> >   ...
> > 
> > Here RUN_TESTS is a macro defined in test_progs.h, it expands to a
> > code that uses test_loader.c:test_loader__run_subtests() function to
> > load tests specified by appropriate skel.h.
> > 
> > In order to get the list of tests included in
> > 'test_loader_auto_wrappers.c' the generation script looks for
> > 'progs/*.c' files that contain a special comment:
> > 
> >   /* Use test_loader marker */
> > 
> > Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
> > ---
> 
> It feels like this is a bit of an overkill, tbh. There are
> 
> $ ls verifier/*.c | wc -l
> 94
> 
> files. We can move each migrated set of tests from verifier/xxx.c to
> progs/verifier_xxx.c. And then just have just manually maintained
> prog_tests/verifier.c file where for each converted test we have one
> #include and one void test_some_test_1(void) { RUN_TESTS(some_test_1);
> }.
> 
> It sometimes would useful to add some extra debugging printfs in such
> a file, so having it auto generated would be actually an
> inconvenience. And that on top of further Makefile complication.
> 
> For initial conversion we can auto-generate this file, of course. And
> then for each migrated file adding 2 lines manually doesn't seem like
> a big deal?

Ok, I'll remove the makefile changes.

> 
> 
> 
> >  tools/testing/selftests/bpf/Makefile          | 34 +++++++++++++++++++
> >  .../selftests/bpf/prog_tests/.gitignore       |  1 +
> >  2 files changed, 35 insertions(+)
> > 
> 
> [...]


  reply	other threads:[~2023-01-26 23:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-23 14:51 [RFC bpf-next 0/5] test_verifier tests migration to inline assembly Eduard Zingerman
2023-01-23 14:51 ` [RFC bpf-next 1/5] selftests/bpf: support custom per-test flags and multiple expected messages Eduard Zingerman
2023-02-28 18:53   ` Andrii Nakryiko
2023-02-28 22:30     ` Eduard Zingerman
2023-03-01 17:12       ` Andrii Nakryiko
2023-03-01 17:58         ` Eduard Zingerman
2023-01-23 14:51 ` [RFC bpf-next 2/5] selftests/bpf: unprivileged tests for test_loader.c Eduard Zingerman
2023-01-23 14:51 ` [RFC bpf-next 3/5] selftests/bpf: generate boilerplate code for test_loader-based tests Eduard Zingerman
2023-01-26  1:43   ` Andrii Nakryiko
2023-01-26 23:29     ` Eduard Zingerman [this message]
2023-01-23 14:51 ` [RFC bpf-next 4/5] selftests/bpf: __imm_insn macro to embed raw insns in inline asm Eduard Zingerman
2023-01-26  2:48   ` Andrii Nakryiko
2023-01-23 14:51 ` [RFC bpf-next 5/5] selftests/bpf: convert jeq_infer_not_null tests to inline assembly Eduard Zingerman
2023-01-26  1:33 ` [RFC bpf-next 0/5] test_verifier tests migration " Andrii Nakryiko
2023-01-26  3:25   ` Alexei Starovoitov
2023-01-27  0:43     ` Eduard Zingerman
2023-01-27  0:30   ` Eduard Zingerman
2023-01-27 17:41     ` Andrii Nakryiko

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=aff79e80ef4ae0751f82de42b761b6f27355db1a.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=yhs@fb.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.