From: Daniel Borkmann <daniel@iogearbox.net>
To: Andrii Nakryiko <andriin@fb.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, ast@fb.com,
andrii.nakryiko@gmail.com, kernel-team@fb.com
Subject: Re: [PATCH v4 bpf-next 2/4] libbpf: support libbpf-provided extern variables
Date: Mon, 16 Dec 2019 13:43:47 +0100 [thread overview]
Message-ID: <20191216124347.GB14887@linux.fritz.box> (raw)
In-Reply-To: <20191214014710.3449601-3-andriin@fb.com>
On Fri, Dec 13, 2019 at 05:47:08PM -0800, Andrii Nakryiko wrote:
[...]
> Config file itself is searched in /boot/config-$(uname -r) location with
> fallback to /proc/config.gz, unless config path is specified explicitly
> through bpf_object_open_opts' kernel_config_path option. Both gzipped and
> plain text formats are supported. Libbpf adds explicit dependency on zlib
> because of this, but this shouldn't be a problem, given libelf already depends
> on zlib.
Hm, given this seems to break the build and is not an essential feature,
can't we use the feature detection from tooling infra which you invoke
anyway to compile out bpf_object__read_kernel_config() internals and return
an error there? Build could warn perf-style what won't be available for
the user in that case.
https://patchwork.ozlabs.org/patch/1210213/
Also, does libbpf.pc.template need updating wrt zlib?
next prev parent reply other threads:[~2019-12-16 12:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-14 1:47 [PATCH v4 bpf-next 0/4] Add libbpf-provided extern variables support Andrii Nakryiko
2019-12-14 1:47 ` [PATCH v4 bpf-next 1/4] libbpf: extract internal map names into constants Andrii Nakryiko
2019-12-14 1:47 ` [PATCH v4 bpf-next 2/4] libbpf: support libbpf-provided extern variables Andrii Nakryiko
2019-12-14 12:50 ` Toke Høiland-Jørgensen
2019-12-14 20:27 ` Yonghong Song
2019-12-16 11:17 ` Daniel Borkmann
2019-12-16 19:29 ` Andrii Nakryiko
2019-12-17 14:42 ` Daniel Borkmann
2019-12-17 19:03 ` Andrii Nakryiko
2019-12-17 19:50 ` Daniel Borkmann
2019-12-17 20:16 ` Alexei Starovoitov
2019-12-17 23:37 ` Daniel Borkmann
2019-12-18 0:08 ` Andrii Nakryiko
2019-12-16 12:43 ` Daniel Borkmann [this message]
2019-12-16 18:19 ` Andrii Nakryiko
2019-12-14 1:47 ` [PATCH v4 bpf-next 3/4] bpftool: generate externs datasec in BPF skeleton Andrii Nakryiko
2019-12-14 1:47 ` [PATCH v4 bpf-next 4/4] selftests/bpf: add tests for libbpf-provided externs Andrii Nakryiko
2019-12-16 0:52 ` [PATCH v4 bpf-next 0/4] Add libbpf-provided extern variables support Alexei Starovoitov
2019-12-16 1:47 ` Andrii Nakryiko
2019-12-16 4:42 ` Alexei Starovoitov
2019-12-16 19:34 ` 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=20191216124347.GB14887@linux.fritz.box \
--to=daniel@iogearbox.net \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=kernel-team@fb.com \
--cc=netdev@vger.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.