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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 27509C432C0 for ; Wed, 4 Dec 2019 05:52:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E6917207DD for ; Wed, 4 Dec 2019 05:52:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RanmOx1f" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726917AbfLDFwZ (ORCPT ); Wed, 4 Dec 2019 00:52:25 -0500 Received: from mail-lf1-f67.google.com ([209.85.167.67]:38466 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725776AbfLDFwZ (ORCPT ); Wed, 4 Dec 2019 00:52:25 -0500 Received: by mail-lf1-f67.google.com with SMTP id r14so5074232lfm.5; Tue, 03 Dec 2019 21:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nzbDYaqYcFJ64Z60Mv6NcLPPMn+RWAQ/vTfwfbpf8UM=; b=RanmOx1fbrh/niQDf8eEp6XpWFsE8t6H2dRZhxA+ByP/6AKoTCz+pAgeswWb14vmW9 XUBinc2AdNVUAN5h0YnDkUv1UFWndLC99RYa1ZKCRbSwaDsIQIti1KbV61ZLi1OsTHEb AgmMXG//SUcCqzw6fBbSk7ovUPY7M8TQu5HJb7+KlFRV1W+Xrw+P02UeqB4SUwFhwA2x XsB4TKlaXJGZ5PmRe5t5FkSVRKHGOE4w6YXe8FINPFJB4q6J8PNSa5px1uYIduZdcthX 0QkABRoz6wl/cnKJ1OTClpQrMKkYYmpB5GTvitBR5gtgc2JMV4Hq1up4ZhXj2qd1ERbh +d8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nzbDYaqYcFJ64Z60Mv6NcLPPMn+RWAQ/vTfwfbpf8UM=; b=iEKN+ThH/WGnbtz2zxR0ZtnnAafQowU7dnDEaEz/H2grkvIWOTqaAjhJzAUgbuPm8T U4sGFYZeXAbVTIVtq5+w2iS45QsEOeKpSB7uBHnM08uP3+TBS2LKyKdcAfVpS4yqw6cN ZtrRDDHUi05ScL8KQcG6G5+v6AQS4hfYFamCNFWmbB+mqOjsC9iuf/Q2yQRo0Ez9fxuz xOxS0hRp29vpFJ16zH5RCZQq4hBqYmw2FUKInUAtjlkfGFiVhFoRWYKozZCY71pmpi1N SAPNpOy29dsFHfE1U21TPGFqQzAZ113SzP9Rq5Wch3RnPHXlQbGpYLv/iYDVwBp3hVum GVkg== X-Gm-Message-State: APjAAAX85Jva4ROo2ygkYPtWQEPkPVBk2PAcpVBjAYrs7W99KHHoTHIf HZBNluHstUXk/pQ6noHtQPzbQgwUMVov0HiGzy0= X-Google-Smtp-Source: APXvYqxUV1VzjISq9pBDyL917A+0YWgy6WfDZ55v0BKyRopOIgWIDEKFAyvUryo082rae4zUOK78S7pACe4CB1qsQ9k= X-Received: by 2002:ac2:47ec:: with SMTP id b12mr913547lfp.162.1575438742853; Tue, 03 Dec 2019 21:52:22 -0800 (PST) MIME-Version: 1.0 References: <20191202131847.30837-1-jolsa@kernel.org> <87wobepgy0.fsf@toke.dk> In-Reply-To: <87wobepgy0.fsf@toke.dk> From: Alexei Starovoitov Date: Tue, 3 Dec 2019 21:52:11 -0800 Message-ID: Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Andrii Nakryiko , Jiri Olsa , Arnaldo Carvalho de Melo , lkml , Networking , bpf , Ingo Molnar , Namhyung Kim , Alexander Shishkin , Peter Zijlstra , Michael Petlan , Jesper Dangaard Brouer , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , Quentin Monnet Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 2, 2019 at 1:15 PM Toke H=C3=B8iland-J=C3=B8rgensen 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 =3D=3D version of b= pftool. 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?