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

[Alexei Starovoitov]

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.