Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

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?

> 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?
Tying user space release into kernel release and user space process into
kernel process makes little sense to me. Packaging is different. Compatibility
requirements are different. CI is different. Integration with other projects is
different.

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. Even coding style is
different. I'm puzzled why you think user space should be tied to kernel.
Everything is so vastly different.
Some people say that 8 weeks to bump libbpf version is too long.
Other people say that it's too often.
libbpf version numbers != kernel version numbers.
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.
libbpf has to run on all kernels. Newer and older. How do you support that if
libbpf is tied with the kernel?

> Perhaps I'm not clever enough to follow. But if I'm allowed to make an
> uneducated guess it would be that it's some Facebook internal reason,
> like it's hard to do backports? :/

hard to do backports? of what?