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

[Alexei Starovoitov]

On Wed, Dec 04, 2019 at 08:26:38PM -0800, Jakub Kicinski wrote:
> On Wed, 4 Dec 2019 19:17:20 -0800, Alexei Starovoitov wrote:
> > 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'.
> 
> Perhaps someone else has more patience to explain it - why bcc can't
> just use binary libbpf distribution (static lib + headers) and link
> against it like it links against other libraries?

why systemd considered using libbpf as submodule ?
When project like bcc needs to run on different distros and
different versions of the same distro such project cannot force users
to upgrade core libraries to get features that project might need.
libbpf is far from stability of libc, libmnl, libelf.
There are mature libraries and actively developed libraries.
libbpf is at its infancy stage. We're trying hard to be stable,
but accumulated baggage is already huge and it is slowing us down.
systemd is considering to use libbpf without being submodule too,
but it's mainly driven by systemd's CI limitations and nothing else.

> Share with us what you dislike about iproute2 so we can fix it. 

let's start with 24-hr review cycle that we're trying hard to keep in bpf/net
trees. Can you help with 24-hr review in iproute2 ?

> Because libbpf just now entered the distroes, and you suggested the
> distroes use the GH repo, so sure now it's wasted work.

You got the timeline wrong. GH repo was done before some distros started
packaging libbpf. libbpf is still not available in centos/rhel afaik.
But bcc and bpftrace need to work there. Answer? submodules...

> > Are you trolling? Do you understand why __ is there?
> 
> Not the point. Tell me how the coding style is different. The
> underscores is the only thing I could think of that's not common 
> in the kernel.

we don't actively enforce xmas tree :)

> But master of libbpf must have all features to test the kernel with,
> right? So how do we branch of a release in the middle? That's only
> possible if kernel cycle happens to not have had any features that
> required libbpf yet?

libbpf rate of changes is higher than bpf bits of the kernel.
Amount of patches per week is higher as well.
Something like skeleton work might warrant independent release just
to get into the hands of people faster. Why wait 8 weeks for kernel
release? No reason.

> Or are you thinking 3 tier branching where we'd branch off libbpf
> release, say 2.6.0 that corresponds to kernel X, 

libbpf does not correspond to kernel.
All libbpf releases must work with any kernel.

> but it wouldn't be a
> stable-only release, and we can still backport features added in kernel
> X + 1 cycle, features which don't require kernel support, and release
> libbpf 2.7.0?

Say libbpf 0.1 was developed during kernel 5.4.
We can 'backport' all libbpf features from kernel tree 5.5 into libbpf 0.1+
and that libbpf 0.1+ must work with kernels 5.4 and 5.5.
That is what existing github/libbpf CI is testing.