public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox