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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20191204.162929.2216543178968689201.davem@davemloft.net>
Date:   Wed, 04 Dec 2019 16:29:29 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     unlisted-recipients:; (no To-header on input)
Cc:     alexei.starovoitov@...il.com, andrii.nakryiko@...il.com,
        toke@...hat.com, jolsa@...nel.org, acme@...nel.org,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        bpf@...r.kernel.org, mingo@...nel.org, namhyung@...nel.org,
        alexander.shishkin@...ux.intel.com, a.p.zijlstra@...llo.nl,
        mpetlan@...hat.com, brouer@...hat.com, daniel@...earbox.net,
        kafai@...com, songliubraving@...com, yhs@...com, andriin@...com,
        quentin.monnet@...ronome.com
Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically

From: Jakub Kicinski <jakub.kicinski@...ronome.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.