From: Jakub Kicinski <firstname.lastname@example.org> To: Alexei Starovoitov <email@example.com> Cc: "Andrii Nakryiko" <firstname.lastname@example.org>, "Toke Høiland-Jørgensen" <email@example.com>, "Jiri Olsa" <firstname.lastname@example.org>, "Arnaldo Carvalho de Melo" <email@example.com>, lkml <firstname.lastname@example.org>, Networking <email@example.com>, bpf <firstname.lastname@example.org>, "Ingo Molnar" <email@example.com>, "Namhyung Kim" <firstname.lastname@example.org>, "Alexander Shishkin" <email@example.com>, "Peter Zijlstra" <firstname.lastname@example.org>, "Michael Petlan" <email@example.com>, "Jesper Dangaard Brouer" <firstname.lastname@example.org>, "Daniel Borkmann" <email@example.com>, "Martin KaFai Lau" <firstname.lastname@example.org>, "Song Liu" <email@example.com>, "Yonghong Song" <firstname.lastname@example.org>, "Andrii Nakryiko" <email@example.com>, "Quentin Monnet" <firstname.lastname@example.org> Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically Date: Wed, 4 Dec 2019 18:10:28 -0800 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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. > > You also said a few times you don't want to merge fixes into bpf/net. > > That divergence from kernel development process is worrying. > > worrying - why? what exactly the concern you see? First it's still in the tree so it just feels wrong to have the process fundamentally different for sections of the tree. Secondly it's best to stick to the tried and tested processes unless there's a good and stated reason to diverge. Now we're neither doing standard user library process nor kernel process. Both of which must account for stable fixes (Dave explained the enterprise distro needs in his reply). > Tying user space release into kernel release and user space process into > kernel process makes little sense to me. I'm not saying we can't do user space, but we should pick one. I have slight preference for kernel process, because it's familiar and it automatically takes of policy questions, which otherwise consume developer's time. 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? Let's learn from experience :/ > Packaging is different. There are mostly disadvantages, but the process should be well known. perf has been packaged for years. iproute2 sometimes lags behind the upstream, more than perf in my experience. Also there's rarely a need to update tools closely related to the kernel without the kernel.. > Compatibility requirements are different. True. > CI is different. Well, hard to argue about things which don't exist :/ > Integration with other projects is different. IMHO the submodule use case is fading. dnf/apt install, it's just a normal C library, we've done this for decades. And there is no submodule need for bpftool, which we are discussing. > libbpf source code is in the kernel tree only because kernel changes plus > libbpf changes plus selftests changes come as single patchset. That is really > the only reason. Packaging scripts, CI scripts, etc should be kept out of > kernel tree. All that stuff belongs at github/libbpf. > > > None of this makes very much sense to me. We're diverging from well > > established development practices without as much as a justification. > > The kernel development process was never used for libbpf. What do you mean? I've sure as hell sent patches to net with Fixes tags, S-o-B and all that jazz for libbpf and bpftool. > Even coding style is different. Is it? You mean the damn underscores people are making fun of? :/ > I'm puzzled why you think user space > should be tied to kernel. Everything is so vastly different. Not what I'm saying, I'm saying either run it as user space project in separate repos or kernel project. You're proposing we do both with some syncs and no clear process. > Some people say that 8 weeks to bump libbpf version is too long. > Other people say that it's too often. Those are two conflicting requirements, Alexei, how is breaking apart from the kernel going to make any difference? At least kernel gives us this somewhat reasonable 8 week cadence and we don't have to ponder whether it should be shorter or longer until someone presents us with a compelling reason. > libbpf version numbers != kernel version numbers. Well, libbpf's numbers are arbitrary, and meaningless. They could as well be kernel numbers, like they are for bpftool. Or dates. libbpf doesn't have a roadmap either, it's not really a full-on project on its own. What's 0.1.0 gonna be? 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? Eh, you're just convincing me it should just stay in the kernel now. > There is no definition of LTS for libbpf. One day it will be > and the version of libbpf picked for LTS will likely have > nothing to do with kernel LTS choices. Again, libbpf inherits the kernel process so there is LTS process, the kernel one, and it's taken care of for us by all the existing stable automation. By merging everything into -next you're loosing that, with all but a vague mirage of how there may one day be multiple stable branches.. > 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. Sorry for the long response.
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 [this message] 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 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 \ --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 \ --firstname.lastname@example.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
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 \ email@example.com 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