From: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
To: "Alexis Lothoré" <alexis.lothore@bootlin.com>,
bpf <bpf@vger.kernel.org>,
linux-kselftest@vger.kernel.org
Cc: Quentin Monnet <qmo@kernel.org>,
"Bastien Curutchet (eBPF Foundation)"
<bastien.curutchet@bootlin.com>
Subject: Re: [Question] json parsing and bpf selftests dependencies
Date: Thu, 26 Feb 2026 15:01:47 +0000 [thread overview]
Message-ID: <87ldgfpmzo.fsf@gmail.com> (raw)
In-Reply-To: <DGOTPHTTR5ZE.Q7ALRR86ZZ6N@bootlin.com>
Alexis Lothoré <alexis.lothore@bootlin.com> writes:
> Hello,
> I am pursuing my quest to convert standalone bpf tests (from
> tools/testing/selftests/bpf) into the test_progs framework so they can
> be executed automatically by the CI tooling.
>
> I would like to continue on the bpftool tests, especially
> test_bpftool.py ([1]). This one involves quite a lot of json parsing on
> bpftool output (to validate that some entries are present in the
> output, depending on the used command), which does not seem to be a use
> case currently in bpf selftests. The first tests may be handled by some
> manual parsing (eg strstr'ing keys in the output, that's what I've done
> for the recently converted bpftool_metadata test, see [2]), but that's a
> bit fragile, and there are more complex subtests for which this loosy
> strategy will get even more fragile (eg
> test_feature_kernel_full_vs_not_full generates json output with two
> different commands, and tests the diff).
>
> I then face the need to have some proper json parsing in test_progs. I
> kind of understand that there is a will to keep the dependency list
> small for test_progs, so I'm asking here what could be the best option
> for this:
> - is it ok to make test_progs depend on a new json parsing library (eg:
> cJSON) ? and so add the library to CI images ?
> - or some implicit dependency on some CLI tooling (eg: jq) ? and so, add
> the cli tool to CI images ?
> - test_progs is reusing json_writer.c from bpftool ([2]), should we
> rather write a custom json_reader.c as well (even if not needed at
> that point by bpftool itself) ?
>
> Any opinion on this ?
Can we please make that test_progs can be built without json deps and
run tests that do not require them, it's useful because we build tests
in a restricted container image, where adding a new library may be
undesirable (I'm not talking about github CI).
>
> Alexis
>
> [1] https://elixir.bootlin.com/linux/v6.19.3/source/tools/testing/selftests/bpf/test_bpftool.py
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/prog_tests/bpftool_metadata.c#n49
> [3] https://elixir.bootlin.com/linux/v6.19.3/source/tools/bpf/bpftool/json_writer.c
>
> --
> Alexis Lothoré, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
next prev parent reply other threads:[~2026-02-26 15:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 10:32 [Question] json parsing and bpf selftests dependencies Alexis Lothoré
2026-02-26 15:01 ` Mykyta Yatsenko [this message]
2026-02-26 17:21 ` Alexei Starovoitov
2026-02-27 7:31 ` Alexis Lothoré
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=87ldgfpmzo.fsf@gmail.com \
--to=mykyta.yatsenko5@gmail.com \
--cc=alexis.lothore@bootlin.com \
--cc=bastien.curutchet@bootlin.com \
--cc=bpf@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=qmo@kernel.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 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.