Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 4 Dec 2019 17:25:26 -0800
From:   Alexei Starovoitov <alexei.starovoitov@gmail.com>
To:     David Miller <davem@davemloft.net>
Cc:     andrii.nakryiko@gmail.com, toke@redhat.com, jolsa@kernel.org,
        acme@kernel.org, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, bpf@vger.kernel.org, mingo@kernel.org,
        namhyung@kernel.org, alexander.shishkin@linux.intel.com,
        a.p.zijlstra@chello.nl, mpetlan@redhat.com, brouer@redhat.com,
        daniel@iogearbox.net, kafai@fb.com, songliubraving@fb.com,
        yhs@fb.com, andriin@fb.com, quentin.monnet@netronome.com
Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically
Message-ID: <20191205012525.lpp5ilieupftpqrd@ast-mbp.dhcp.thefacebook.com>
References: <20191204135405.3ffb9ad6@cakuba.netronome.com>
 <20191204233948.opvlopjkxe5o66lr@ast-mbp.dhcp.thefacebook.com>
 <20191204162348.49be5f1b@cakuba.netronome.com>
 <20191204.162929.2216543178968689201.davem@davemloft.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191204.162929.2216543178968689201.davem@davemloft.net>
User-Agent: NeoMutt/20180223
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Dec 04, 2019 at 04:29:29PM -0800, David Miller wrote:
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Date: Wed, 4 Dec 2019 16:23:48 -0800
> 
> > Jokes aside, you may need to provide some reasoning on this one..
> > The recommendation for packaging libbpf from GitHub never had any 
> > clear justification either AFAICR.
> > 
> > I honestly don't see why location matters. bpftool started out on GitHub
> > but we moved it into the tree for... ease of packaging/distribution(?!)
> > Now it's handy to have it in the tree to reuse the uapi headers.
> > 
> > As much as I don't care if we move it (back) out of the tree - having
> > two copies makes no sense to me. As does having it in the libbpf repo.
> > The sync effort is not warranted. User confusion is not warranted.
> 
> Part of this story has to do with how bug fixes propagate via bpf-next
> instead of the bpf tree, as I understand it.
> 
> But yeah it would be nice to have a clear documentation on all of the
> reasoning.
> 
> On the distro side, people seem to not want to use the separate repo.
> If you're supporting enterprise customers you don't just sync with
> upstream, you cherry pick.  When cherry picking gets too painful, you
> sync with upstream possibly eliding upstream new features you don't
> want to appear in your supported product yet.
> 
> I agree with tying bpftool and libbpf into the _resulting_ binary
> distro package, but I'm not totally convinced about separating them
> out of the kernel source tree.

Looks like there is a confusion here.
I'm not proposing to move bpftool out of kernel tree.
The kernel+libbpf+bpftool+selftests already come as single patch set.
bpftool has to stay in the kernel tree otherwise things like skeleton
patchset won't be possible to accomplish without a lot of coordination
between different trees and propagation delays.

I'm proposing to tweak github/libbpf sync script to sync bpftool
sources from kernel into github, so both libbpf and bpftool can be
tested and packaged together.
People are working on adding proper CI to github/libbpf.
bpftool testing will automatically get more mileage out of that effort.

github/libbpf is self contained. It should be built and tested
on many different kernels and build environments (like any user
space package should be). That's an important goal of CI.
When bpftool is part of github/libbpf it will get the same treatment.
I see only advantages and not a single disadvantage of building,
testing, packaging bpftool out of github/libbpf.

To support stable libbpf+bpftool releases we can branch in github and push
fixes into branches. Same CI can test master and stable branches.