BPF Archive on lore.kernel.org
 help / color / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Michael Petlan <mpetlan@redhat.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>, Andrii Nakryiko <andriin@fb.com>,
	Quentin Monnet <quentin.monnet@netronome.com>
Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically
Date: Wed, 04 Dec 2019 21:22:53 +0100
Message-ID: <874kyfon6q.fsf@toke.dk> (raw)
In-Reply-To: <20191204182727.GA29780@localhost.localdomain>

Daniel Borkmann <daniel@iogearbox.net> 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øiland-Jørgensen <toke@redhat.com> wrote:
>> > Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
>> > > On Mon, Dec 2, 2019 at 1:15 PM Toke Høiland-Jørgensen <toke@redhat.com> 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.

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


  reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-02 13:18 Jiri Olsa
2019-12-02 13:18 ` [PATCH 1/6] perf tools: Allow to specify libbpf install directory Jiri Olsa
2019-12-02 13:18 ` [PATCH 2/6] bpftool: Allow to link libbpf dynamically Jiri Olsa
2019-12-02 13:18 ` [PATCH 3/6] bpftool: Rename BPF_DIR Makefile variable to LIBBPF_SRC_DIR Jiri Olsa
2019-12-02 13:18 ` [PATCH 4/6] bpftool: Rename LIBBPF_OUTPUT Makefile variable to LIBBPF_BUILD_OUTPUT Jiri Olsa
2019-12-02 13:18 ` [PATCH 5/6] bpftool: Rename LIBBPF_PATH Makefile variable to LIBBPF_BUILD_PATH Jiri Olsa
2019-12-02 13:18 ` [PATCH 6/6] selftests, bpftool: Add build test for libbpf dynamic linking Jiri Olsa
2019-12-02 15:38   ` Quentin Monnet
2019-12-02 19:41 ` [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically Andrii Nakryiko
2019-12-02 21:15   ` Toke Høiland-Jørgensen
2019-12-04  5:52     ` Alexei Starovoitov
2019-12-04  9:01       ` Jiri Olsa
2019-12-04 10:57       ` Toke Høiland-Jørgensen
2019-12-04 17:39         ` Alexei Starovoitov
2019-12-04 18:27           ` Daniel Borkmann
2019-12-04 20:22             ` Toke Høiland-Jørgensen [this message]
2019-12-04 21:16       ` Andrii Nakryiko
2019-12-04 21:54         ` Jakub Kicinski
2019-12-04 23:39           ` Alexei Starovoitov
2019-12-05  0:23             ` Jakub Kicinski
2019-12-05  0:29               ` David Miller
2019-12-05  1:25                 ` Alexei Starovoitov
2019-12-05  1:09               ` Alexei Starovoitov
2019-12-05  2:10                 ` Jakub Kicinski
2019-12-05  3:17                   ` Alexei Starovoitov
2019-12-05  4:26                     ` Jakub Kicinski
2019-12-05  6:44                       ` Alexei Starovoitov
2019-12-05  8:35             ` Jesper Dangaard Brouer
2019-12-05 12:09               ` Michal Rostecki

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874kyfon6q.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mpetlan@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=quentin.monnet@netronome.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

BPF Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \
		bpf@vger.kernel.org
	public-inbox-index bpf

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.bpf


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git