From: David Miller <davem@davemloft.net>
To: unlisted-recipients:; (no To-header on input)
Cc: alexei.starovoitov@gmail.com, andrii.nakryiko@gmail.com,
toke@redhat.com, jolsa@kernel.org, acme@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
bpf@vger.kernel.org, mingo@kernel.org, namhyung@kernel.org,
alexander.shishkin@linux.intel.com, a.p.zijlstra@chello.nl,
mpetlan@redhat.com, brouer@redhat.com, daniel@iogearbox.net,
kafai@fb.com, songliubraving@fb.com, yhs@fb.com, andriin@fb.com,
quentin.monnet@netronome.com
Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically
Date: Wed, 04 Dec 2019 16:29:29 -0800 (PST) [thread overview]
Message-ID: <20191204.162929.2216543178968689201.davem@davemloft.net> (raw)
In-Reply-To: <20191204162348.49be5f1b@cakuba.netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Wed, 4 Dec 2019 16:23:48 -0800
> Jokes aside, you may need to provide some reasoning on this one..
> The recommendation for packaging libbpf from GitHub never had any
> clear justification either AFAICR.
>
> I honestly don't see why location matters. bpftool started out on GitHub
> but we moved it into the tree for... ease of packaging/distribution(?!)
> Now it's handy to have it in the tree to reuse the uapi headers.
>
> As much as I don't care if we move it (back) out of the tree - having
> two copies makes no sense to me. As does having it in the libbpf repo.
> The sync effort is not warranted. User confusion is not warranted.
Part of this story has to do with how bug fixes propagate via bpf-next
instead of the bpf tree, as I understand it.
But yeah it would be nice to have a clear documentation on all of the
reasoning.
On the distro side, people seem to not want to use the separate repo.
If you're supporting enterprise customers you don't just sync with
upstream, you cherry pick. When cherry picking gets too painful, you
sync with upstream possibly eliding upstream new features you don't
want to appear in your supported product yet.
I agree with tying bpftool and libbpf into the _resulting_ binary
distro package, but I'm not totally convinced about separating them
out of the kernel source tree.
next prev parent reply other threads:[~2019-12-05 0:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-02 13:18 [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically Jiri Olsa
2019-12-02 13:18 ` [PATCH 1/6] perf tools: Allow to specify libbpf install directory Jiri Olsa
2019-12-02 13:18 ` [PATCH 2/6] bpftool: Allow to link libbpf dynamically Jiri Olsa
2019-12-02 13:18 ` [PATCH 3/6] bpftool: Rename BPF_DIR Makefile variable to LIBBPF_SRC_DIR Jiri Olsa
2019-12-02 13:18 ` [PATCH 4/6] bpftool: Rename LIBBPF_OUTPUT Makefile variable to LIBBPF_BUILD_OUTPUT Jiri Olsa
2019-12-02 13:18 ` [PATCH 5/6] bpftool: Rename LIBBPF_PATH Makefile variable to LIBBPF_BUILD_PATH Jiri Olsa
2019-12-02 13:18 ` [PATCH 6/6] selftests, bpftool: Add build test for libbpf dynamic linking Jiri Olsa
2019-12-02 15:38 ` Quentin Monnet
2019-12-02 19:41 ` [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically Andrii Nakryiko
2019-12-02 21:15 ` Toke Høiland-Jørgensen
2019-12-04 5:52 ` Alexei Starovoitov
2019-12-04 9:01 ` Jiri Olsa
2019-12-04 10:57 ` Toke Høiland-Jørgensen
2019-12-04 17:39 ` Alexei Starovoitov
2019-12-04 18:27 ` Daniel Borkmann
2019-12-04 20:22 ` Toke Høiland-Jørgensen
2019-12-04 21:16 ` Andrii Nakryiko
2019-12-04 21:54 ` Jakub Kicinski
2019-12-04 23:39 ` Alexei Starovoitov
2019-12-05 0:23 ` Jakub Kicinski
2019-12-05 0:29 ` David Miller [this message]
2019-12-05 1:25 ` Alexei Starovoitov
2019-12-05 1:09 ` Alexei Starovoitov
2019-12-05 2:10 ` Jakub Kicinski
2019-12-05 3:17 ` Alexei Starovoitov
2019-12-05 4:26 ` Jakub Kicinski
2019-12-05 6:44 ` Alexei Starovoitov
2019-12-05 8:35 ` Jesper Dangaard Brouer
2019-12-05 12:09 ` Michal Rostecki
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=20191204.162929.2216543178968689201.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mpetlan@redhat.com \
--cc=namhyung@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=quentin.monnet@netronome.com \
--cc=songliubraving@fb.com \
--cc=toke@redhat.com \
--cc=yhs@fb.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;
as well as URLs for NNTP newsgroup(s).