All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.