From: Quentin Monnet <qmo@kernel.org>
To: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>,
bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org,
daniel@iogearbox.net, kafai@meta.com, kernel-team@meta.com,
eddyz87@gmail.com
Cc: Mykyta Yatsenko <yatsenko@meta.com>
Subject: Re: [PATCH bpf-next v2] bpftool: Allow explicitly skip llvm, libbfd and libcrypto dependencies
Date: Sat, 21 Mar 2026 00:50:45 +0000 [thread overview]
Message-ID: <ea4b6626-e435-4044-a671-35f5c18e3ce6@kernel.org> (raw)
In-Reply-To: <ad8a783b-7b8c-46f2-9a3c-953315aafe38@kernel.org>
2026-03-17 10:29 UTC+0000 ~ Quentin Monnet <qmo@kernel.org>
> 2026-03-12 17:03 UTC-0700 ~ Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
>> From: Mykyta Yatsenko <yatsenko@meta.com>
>>
>> Introduce SKIP_LLVM, SKIP_LIBBFD, and SKIP_CRYPTO build flags that let
>> users build bpftool without these optional dependencies.
>>
>> SKIP_LLVM=1 skips LLVM even when detected. SKIP_LIBBFD=1 prevents the
>> libbfd JIT disassembly fallback when LLVM is absent. Together, they
>> produce a bpftool with no disassembly support.
>>
>> SKIP_CRYPTO=1 excludes sign.c and removes the -lcrypto link dependency.
>> Inline stubs in main.h return errors with a clear message if signing
>> functions are called at runtime.
>>
>> Use BPFTOOL_WITHOUT_CRYPTO (not HAVE_LIBCRYPTO_SUPPORT) as the C
>> define, following the BPFTOOL_WITHOUT_SKELETONS naming convention for
>> bpftool-internal build config, leaving HAVE_LIBCRYPTO_SUPPORT free for
>> proper feature detection in the future.
>>
>> All three flags are propagated through the selftests Makefile to bpftool
>> sub-builds.
>>
>> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
>
>
> Sorry I'm late for this one, I see Andrii applied it - I just wanted to
> say thank you for this!
Mykyta, Andrii,
Apologies again for missing the review on this series. I'm realising
only now that it goes beyond what we initially discussed: It adds a way
to turn off the optional dependencies related to the disassemblers,
which is what we agreed on, but it also makes libcrypto optional.
There were previous discussions where I pushed back against making
program signing optional in bpftool. It's one thing to have the JIT
disassembler unavailable on a machine; but it's going to be a pain if a
policy requires signed programs on a system, but the bpftool version
available does not support signing. Are you really sure you want to make
it optional? My preference would be to keep program signing a mandatory
feature for bpftool going forward.
Best regards,
Quentin
next prev parent reply other threads:[~2026-03-21 0:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 0:03 [PATCH bpf-next v2] bpftool: Allow explicitly skip llvm, libbfd and libcrypto dependencies Mykyta Yatsenko
2026-03-16 21:20 ` patchwork-bot+netdevbpf
2026-03-17 10:29 ` Quentin Monnet
2026-03-21 0:50 ` Quentin Monnet [this message]
2026-03-23 18:35 ` Mykyta Yatsenko
2026-03-23 20:21 ` Andrii Nakryiko
2026-03-25 17:49 ` Quentin Monnet
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=ea4b6626-e435-4044-a671-35f5c18e3ce6@kernel.org \
--to=qmo@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kafai@meta.com \
--cc=kernel-team@meta.com \
--cc=mykyta.yatsenko5@gmail.com \
--cc=yatsenko@meta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox