From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A870C43603 for ; Wed, 4 Dec 2019 18:27:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 76DB2205F4 for ; Wed, 4 Dec 2019 18:27:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729223AbfLDS1k (ORCPT ); Wed, 4 Dec 2019 13:27:40 -0500 Received: from www62.your-server.de ([213.133.104.62]:40604 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729345AbfLDS1k (ORCPT ); Wed, 4 Dec 2019 13:27:40 -0500 Received: from [194.230.159.159] (helo=localhost) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1icZN2-0004rF-GG; Wed, 04 Dec 2019 19:27:28 +0100 Date: Wed, 4 Dec 2019 19:27:27 +0100 From: Daniel Borkmann To: Alexei Starovoitov Cc: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= , Andrii Nakryiko , Jiri Olsa , Arnaldo Carvalho de Melo , lkml , Networking , bpf , Ingo Molnar , Namhyung Kim , Alexander Shishkin , Peter Zijlstra , Michael Petlan , Jesper Dangaard Brouer , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , Quentin Monnet Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically Message-ID: <20191204182727.GA29780@localhost.localdomain> References: <20191202131847.30837-1-jolsa@kernel.org> <87wobepgy0.fsf@toke.dk> <877e3cpdc9.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.101.4/25653/Wed Dec 4 10:46:42 2019) Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Wed, Dec 04, 2019 at 09:39:59AM -0800, Alexei Starovoitov wrote: > On Wed, Dec 4, 2019 at 2:58 AM Toke Høiland-Jørgensen wrote: > > Alexei Starovoitov writes: > > > On Mon, Dec 2, 2019 at 1:15 PM Toke Høiland-Jørgensen wrote: > > >> > > >> Ah, that is my mistake: I was getting dynamic libbpf symbols with this > > >> approach, but that was because I had the version of libbpf.so in my > > >> $LIBDIR that had the patch to expose the netlink APIs as versioned > > >> symbols; so it was just pulling in everything from the shared library. > > >> > > >> So what I was going for was exactly what you described above; but it > > >> seems that doesn't actually work. Too bad, and sorry for wasting your > > >> time on this :/ > > > > > > bpftool is currently tightly coupled with libbpf and very likely > > > in the future the dependency will be even tighter. > > > In that sense bpftool is an extension of libbpf and libbpf is an extension > > > of bpftool. > > > Andrii is working on set of patches to generate user space .c code > > > from bpf program. > > > bpftool will be generating the code that is specific for the version > > > bpftool and for > > > the version of libbpf. There will be compatibility layers as usual. > > > But in general the situation where a bug in libbpf is so criticial > > > that bpftool needs to repackaged is imo less likely than a bug in > > > bpftool that will require re-packaging of libbpf. > > > bpftool is quite special. It's not a typical user of libbpf. > > > The other way around is more correct. libbpf is a user of the code > > > that bpftool generates and both depend on each other. > > > perf on the other side is what typical user space app that uses > > > libbpf will look like. > > > I think keeping bpftool in the kernel while packaging libbpf > > > out of github was an oversight. > > > I think we need to mirror bpftool into github/libbpf as well > > > and make sure they stay together. The version of libbpf == version of bpftool. > > > Both should come from the same package and so on. > > > May be they can be two different packages but > > > upgrading one should trigger upgrade of another and vice versa. > > > I think one package would be easier though. > > > Thoughts? > > > > Yup, making bpftool explicitly the "libbpf command line interface" makes > > sense and would help clarify the relationship between the two. As Jiri > > said, we are already moving in that direction packaging-wise... > > Awesome. Let's figure out the logistics. > Should we do: > git mv tools/bpf/bpftool/ tools/lib/bpf/ > and appropriate adjustment to Makefiles ? > or keep it where it is and only add to > https://github.com/libbpf/libbpf/blob/master/scripts/sync-kernel.sh ? I'd be in preference of the latter aka keeping where it is. Thanks, Daniel