From: Alexei Starovoitov <email@example.com> To: Jakub Kicinski <firstname.lastname@example.org> Cc: "Andrii Nakryiko" <email@example.com>, "Toke Høiland-Jørgensen" <firstname.lastname@example.org>, "Jiri Olsa" <email@example.com>, "Arnaldo Carvalho de Melo" <firstname.lastname@example.org>, lkml <email@example.com>, Networking <firstname.lastname@example.org>, bpf <email@example.com>, "Ingo Molnar" <firstname.lastname@example.org>, "Namhyung Kim" <email@example.com>, "Alexander Shishkin" <firstname.lastname@example.org>, "Peter Zijlstra" <email@example.com>, "Michael Petlan" <firstname.lastname@example.org>, "Jesper Dangaard Brouer" <email@example.com>, "Daniel Borkmann" <firstname.lastname@example.org>, "Martin KaFai Lau" <email@example.com>, "Song Liu" <firstname.lastname@example.org>, "Yonghong Song" <email@example.com>, "Andrii Nakryiko" <firstname.lastname@example.org>, "Quentin Monnet" <email@example.com> Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically Date: Wed, 4 Dec 2019 19:17:20 -0800 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On Wed, Dec 04, 2019 at 06:10:28PM -0800, Jakub Kicinski wrote: > On Wed, 4 Dec 2019 17:09:32 -0800, Alexei Starovoitov wrote: > > On Wed, Dec 04, 2019 at 04:23:48PM -0800, Jakub Kicinski wrote: > > > On Wed, 4 Dec 2019 15:39:49 -0800, Alexei Starovoitov wrote: > > > > > Agreed. Having libbpf on GH is definitely useful today, but one can hope > > > > > a day will come when distroes will get up to speed on packaging libbpf, > > > > > and perhaps we can retire it? Maybe 2, 3 years from now? Putting > > > > > bpftool in the same boat is just more baggage. > > > > > > > > Distros should be packaging libbpf and bpftool from single repo on github. > > > > Kernel tree is for packaging kernel. > > > > > > Okay, single repo on GitHub: > > > > > > https://github.com/torvalds/linux > > > > and how will you git submodule only libbpf part of kernel github into bcc > > and other projects? > > Why does bcc have to submodule libbpf? Is it in a "special > relationship" with libbpf as well? > > dnf/apt install libbpf > > Or rather: > > dnf/apt install bcc > > since BCC's user doesn't care about dependencies. The day distroes > started packaging libbpf and bpftool the game has changed. have you ever built bcc ? or bpftrace? I'm not sure how to answer such 'suggestion'. > Please accept iproute2 as an example of a user space toolset closely > related to the kernel. If kernel release model and process made no > sense in user space, why do iproute2s developers continue to follow it > for years? imo iproute2 is an example how things should not be run. But that's a very different topic. > > Packaging is different. > > There are mostly disadvantages, but the process should be well known. > perf has been packaged for years. perf was initially seen as something that should match kernel one to one. yet it diverged over years. I think it's a counter example. > What do you mean? I've sure as hell sent patches to net with Fixes tags which was complete waste of time for people who were sending these patches, for maintainers who applied them and for all stables folks who carried them into kernel stable releases. Not a single libbpf build was made out of those sources. > S-o-B and all that jazz for libbpf and bpftool. Many open source projects use SOB. It's not kernel specific. > > > Even coding style is different. > > Is it? You mean the damn underscores people are making fun of? :/ Are you trolling? Do you understand why __ is there? > libbpf doesn't have a roadmap either, I think you're contrasting that with kernel and saying that kernel has a roadmap ? What is kernel roadmap? > it's not really a full-on project > on its own. What's 0.1.0 gonna be? whenever this bpf community decides to call it 0.1.0. > Besides stuff lands in libbpf before it hits a major kernel release. > So how are you gonna make libbpf releases independently from kernel > ones? What if a feature gets a last minute revert in the kernel and it's > in libbpf's ABI? You mean when kernel gets new feature, then libbpf gets new feature, then libbpf is released, but then kernel feature is reverted? Obviously we should avoid making a libbpf release that relies on kernel features that didn't reach the mainline. Yet there could be plenty of reasons why making libbpf release in the middle of kernel development cycle makes perfect sense. Also reaching Linus's tree in rc1 is also not a guarantee of non-revert. Yet we release libbpf around rc1 because everyone expects bug-fixes after rc1. So it's an exception that solidifies the rule. > > libbpf has to run on all kernels. Newer and older. How do you support > > that if libbpf is tied with the kernel? > > Say I have built N kernels UM or for a VM, and we have some test > suite: I pull libbpf, build it, run its tests. The only difference > between in tree and out of tree is that "pull libbpf" means pulling > smaller or larger repo. Doesn't matter that match, it's a low --depth > local clone. The expected CI is: 1. pull-req proposed. 2. CI picks it up, builds, run tests. 3. humans see results and land or reject pull-req. Now try to think through how CI on top of full kernel tree will be able to pick just the right commits to start build/test cycle. Is it going to cherry-pick from patchworks? That would be awesome. Yet intel 0bot results show that it's easier said than done. I'm not saying it's not possible. Just complex. If you have cycles to integrate *-next into kernelci.org, please go ahead.
next prev parent reply index Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-02 13:18 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 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 [this message] 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 publically 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
Netdev Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/netdev/0 netdev/git/0.git git clone --mirror https://lore.kernel.org/netdev/1 netdev/git/1.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 netdev netdev/ https://lore.kernel.org/netdev \ firstname.lastname@example.org public-inbox-index netdev Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.netdev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git