Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp873384ybl; Wed, 4 Dec 2019 12:23:43 -0800 (PST) X-Google-Smtp-Source: APXvYqxQfHOV4vK/df2GV2WFD671uM1eR8/UdLbYGOgJEvtxdvf1UoLQ7j1pXN2Bn3GWlolju1ze X-Received: by 2002:aca:ac88:: with SMTP id v130mr3991514oie.123.1575491023038; Wed, 04 Dec 2019 12:23:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575491023; cv=none; d=google.com; s=arc-20160816; b=etFtDIRtc3EJK6IF1qlBeV5iZlPRM16za0gpJ3puMx+a6kJruptpBNuwFj0EKGu+I9 lF2cyibOjm8CCHVb6gli9FtYB6eCfDcQ6sBs1p0N2A9D9d2UwzV0LnSD+RwZ6ABYKOlp 0WHaotTpcEu3tHWNm8T5AC/D1R1qMLHjYE1/SKKsylee4z2VwTfUBVXV0NDb7qQ2U+ef G/t28SyTJmXvjosOCCLuoLuPuln61RBy76RtJfHcDAGtuBNLOfnk5IGAkAONTXU9L69A YXvZ91SxIPCyNZra7XgWhpEPNvxT4+IfTHs4qr/UwXw+B5gM6zCYjnmwaD++Dy0fiqQ6 LwEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:references:in-reply-to:subject:cc:to:from :dkim-signature; bh=B6501AeuCH09kqXayTpJahOroJlNswm8cYGVnammuGQ=; b=G9Fb3R81vO8MFrEChWmfhXp4HZKpjVNRsvJAx63Rl/gF85J/bxwya+matnGWECXKbD E0FEnXcO+8IJDBWpGEmjqe1fCWdxhEzQ1QJoFYgOxTf7V3xxiCT9HCuukUmSjZZBRMyZ cgGk9DGFCoVsOJBUnn1SpNA5noqRVa6e/op4yK5c0I5S6Gtwzt3tkD3Fki2s59K9WDIS 5UOMqZGQIEeuGUA0vcvaqtOZfvs1OvqnDEPbrFkeZDTTdIhGv+FFlW/JfSzWC8XnE3bs i+YUDdr7y06f5gsWCj8dd/IlixNEAUcGbZw9DDxgxLvaq806uQWmJqmzpUwWJFDmSP/j oyUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cmEl7UJP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i2si2689150otc.130.2019.12.04.12.23.29; Wed, 04 Dec 2019 12:23:43 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cmEl7UJP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728097AbfLDUXA (ORCPT + 99 others); Wed, 4 Dec 2019 15:23:00 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:36306 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727889AbfLDUW7 (ORCPT ); Wed, 4 Dec 2019 15:22:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575490978; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=B6501AeuCH09kqXayTpJahOroJlNswm8cYGVnammuGQ=; b=cmEl7UJPtZNkOCFgzByuvji/lxGXZTLTxng4mY4MiVrRJBR2Fe2yjIhGXDEr7u3gmW6NaC 8PzCCpwJzMGwFcFj8sxEKsWoahfPGhsc+9C1zd5OxyvHrlX4RzVDHw5TQEAtKKAIqCZdFC wT7YRqj4PZBpBamwxI4X0PKw7c1LYXo= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-386-ikl-MifKNlC-sjD-Y9LFSg-1; Wed, 04 Dec 2019 15:22:57 -0500 Received: by mail-lf1-f72.google.com with SMTP id l2so98102lfk.23 for ; Wed, 04 Dec 2019 12:22:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=bWGBRGftecl1TELE+NPWJSQpPs1ATjeROtIx8QlzOM4=; b=oJMnUikiXL3kMZtiTYEgOwYAVHKy9BT7Z4STcMrA6e7+c/yXfkYBY7A6wQYNIezBfA d5dDI71602f1GiSDJQmixmSmMurWtk4UvL8HFikaAcnJoEGH/8jqq5n8/Yy1LrbxaR/X ZsnBr0Gq4Qu5JtqUX81JxcX1DSZ9fIYMvo+7UDEGo/AGKD1KZ4FaqdjzZZbX8TG9QpOu gXn6QKTwh4pFMePBk12E4xi66H494lXF/rd4460DdqggHIAsSWEJab1Pqxe9ybHOo9X+ eXJ37tPOdqxxd/0E/2VO3jTBU1clBKPkqI8pePlhQ1UXMczobIg/QxrPulPX6OLlzN3b qDKQ== X-Gm-Message-State: APjAAAXqJap9ZwEp0Xk0KNOzj9MRlPr/1yc6Nu/gh6ByC5RKR57DZ6ST oIhv6lkYscio3hLOgLhaIvWx8zO8fr4UuCHk2d2aZ7KdfOe3sh+QNjomkkKMFkXp9h5b1Hgri8t rjioJGdeu1SYjUUvmyR38wjOz X-Received: by 2002:ac2:4553:: with SMTP id j19mr3393447lfm.142.1575490975583; Wed, 04 Dec 2019 12:22:55 -0800 (PST) X-Received: by 2002:ac2:4553:: with SMTP id j19mr3393421lfm.142.1575490975321; Wed, 04 Dec 2019 12:22:55 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id o19sm4417121lji.54.2019.12.04.12.22.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Dec 2019 12:22:54 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id C9CAC18193A; Wed, 4 Dec 2019 21:22:53 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Daniel Borkmann , Alexei Starovoitov 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 , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , Quentin Monnet Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically In-Reply-To: <20191204182727.GA29780@localhost.localdomain> References: <20191202131847.30837-1-jolsa@kernel.org> <87wobepgy0.fsf@toke.dk> <877e3cpdc9.fsf@toke.dk> <20191204182727.GA29780@localhost.localdomain> X-Clacks-Overhead: GNU Terry Pratchett Date: Wed, 04 Dec 2019 21:22:53 +0100 Message-ID: <874kyfon6q.fsf@toke.dk> MIME-Version: 1.0 X-MC-Unique: ikl-MifKNlC-sjD-Y9LFSg-1 X-Mimecast-Spam-Score: 0 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 Daniel Borkmann writes: > On Wed, Dec 04, 2019 at 09:39:59AM -0800, Alexei Starovoitov wrote: >> On Wed, Dec 4, 2019 at 2:58 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> > Alexei Starovoitov writes: >> > > 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 t= his >> > >> 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 libra= ry. >> > >> >> > >> So what I was going for was exactly what you described above; but i= t >> > >> seems that doesn't actually work. Too bad, and sorry for wasting yo= ur >> > >> 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 ext= ension >> > > 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 versi= on 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" mak= es >> > sense and would help clarify the relationship between the two. As Jiri >> > said, we are already moving in that direction packaging-wise... >>=20 >> 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. I don't have any strong preference either way. It would make sense to move it to make clear the interdependency (and that bpftool is really the "libbpf cli interface"); but it could also just be kept separate and just document this in the existing bpftool dir. The github repository may need some surgery, though. So maybe let the changes in the kernel tree depend on what's easiest for that? IDK? -Toke