bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Quentin Monnet <quentin@isovalent.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v3 00/10] install libbpf headers when using the library
Date: Thu, 7 Oct 2021 14:24:14 -0700	[thread overview]
Message-ID: <CAEf4BzaQf1tXWpxFZ=2apFZrF-8KM81=ke7W+4Y1JUUTBqDc+g@mail.gmail.com> (raw)
In-Reply-To: <CACdoK4+4iB-aquCgxXV9BYcXZpPrREZrnm+G8hau-SOt8QPtqQ@mail.gmail.com>

On Thu, Oct 7, 2021 at 12:43 PM Quentin Monnet <quentin@isovalent.com> wrote:
>
> On Wed, 6 Oct 2021 at 19:28, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> >
> > On Sun, Oct 3, 2021 at 12:22 PM Quentin Monnet <quentin@isovalent.com> wrote:
> > >
> > > Libbpf is used at several locations in the repository. Most of the time,
> > > the tools relying on it build the library in its own directory, and include
> > > the headers from there. This works, but this is not the cleanest approach.
> > > It generates objects outside of the directory of the tool which is being
> > > built, and it also increases the risk that developers include a header file
> > > internal to libbpf, which is not supposed to be exposed to user
> > > applications.
> > >
> > > This set adjusts all involved Makefiles to make sure that libbpf is built
> > > locally (with respect to the tool's directory or provided build directory),
> > > and by ensuring that "make install_headers" is run from libbpf's Makefile
> > > to export user headers properly.
> > >
> > > This comes at a cost: given that the libbpf was so far mostly compiled in
> > > its own directory by the different components using it, compiling it once
> > > would be enough for all those components. With the new approach, each
> > > component compiles its own version. To mitigate this cost, efforts were
> > > made to reuse the compiled library when possible:
> > >
> > > - Make the bpftool version in samples/bpf reuse the library previously
> > >   compiled for the selftests.
> > > - Make the bpftool version in BPF selftests reuse the library previously
> > >   compiled for the selftests.
> > > - Similarly, make resolve_btfids in BPF selftests reuse the same compiled
> > >   library.
> > > - Similarly, make runqslower in BPF selftests reuse the same compiled
> > >   library; and make it rely on the bpftool version also compiled from the
> > >   selftests (instead of compiling its own version).
> > > - runqslower, when compiled independently, needs its own version of
> > >   bpftool: make them share the same compiled libbpf.
> > >
> > > As a result:
> > >
> > > - Compiling the samples/bpf should compile libbpf just once.
> > > - Compiling the BPF selftests should compile libbpf just once.
> > > - Compiling the kernel (with BTF support) should now lead to compiling
> > >   libbpf twice: one for resolve_btfids, one for kernel/bpf/preload.
> > > - Compiling runqslower individually should compile libbpf just once. Same
> > >   thing for bpftool, resolve_btfids, and kernel/bpf/preload/iterators.
> > >
> > > (Not accounting for the boostrap version of libbpf required by bpftool,
> > > which was already placed under a dedicated .../boostrap/libbpf/ directory,
> > > and for which the count remains unchanged.)
> > >
> > > A few commits in the series also contain drive-by clean-up changes for
> > > bpftool includes, samples/bpf/.gitignore, or test_bpftool_build.sh. Please
> > > refer to individual commit logs for details.
> > >
> > > v3:
> >
> > Please see few problems with libbpf_hdrs phony targets. Seems like
> > they all can be order-only dependencies and not causing unnecessary
> > rebuilds.
>
> Nice catch, I didn't realise it would force rebuilding :(. I'll
> address it in the next version. I'll also add a few adjustments to
> libbpf's and bpftool's Makefiles to make sure we don't recompile when
> not necessary, because of the header files that are currently
> installed unconditionally.
>
> > Can you please also normalize your patch prefixes for bpftool and
> > other tools? We've been using a short and simple "bpftool: " prefix
> > for bpftool-related changes, and for other tools it would be just
> > "tools/runqslower" or "tools/resolve_btfids". Please update
> > accordingly. Thanks!
>
> $ git log --oneline --pretty='format:%s' -- tools/bpf/bpftool/ | \
>         grep -oE '^(bpftool:|tools: bpftool:)' | sort | uniq -c
>    128 bpftool:
>    194 tools: bpftool:
>

But then:

$ git log --oneline --pretty='format:%s' -- tools/testing/selftests/bpf/ | \
        grep -oE '^(selftests/bpf:|selftests: bpf:)' | sort | uniq -c
    925 selftests/bpf:
     98 selftests: bpf:

And if we expand your search a bit:

$ git log --oneline --pretty='format:%s' -- tools/bpf/bpftool/ | \
         grep -oE '^(bpftool:|tools: bpftool:|tools/bpftool:)' | sort | uniq -c
    130 bpftool:
     52 tools/bpftool:
    194 tools: bpftool:

bpftool: + tools/bpftool: almost matches up with tools: bpftool: ;)

I think the most prevailing convention was "dir1/dir2: " style overall.

> ... And “we”'ve been using “tools: bpftool:” since the early days :).
> But yeah sure, I'll adjust. Shorter looks better. Just wondering, are
> those prefixes documented anywhere?

I don't think so.


>
> Thanks,
> Quentin

      reply	other threads:[~2021-10-07 21:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-03 19:21 [PATCH bpf-next v3 00/10] install libbpf headers when using the library Quentin Monnet
2021-10-03 19:21 ` [PATCH bpf-next v3 01/10] tools: bpftool: remove unused includes to <bpf/bpf_gen_internal.h> Quentin Monnet
2021-10-03 19:22 ` [PATCH bpf-next v3 02/10] tools: bpftool: install libbpf headers instead of including the dir Quentin Monnet
2021-10-03 19:22 ` [PATCH bpf-next v3 03/10] tools: resolve_btfids: install libbpf headers when building Quentin Monnet
2021-10-03 19:22 ` [PATCH bpf-next v3 04/10] tools: runqslower: " Quentin Monnet
2021-10-06 18:20   ` Andrii Nakryiko
2021-10-03 19:22 ` [PATCH bpf-next v3 05/10] bpf: preload: " Quentin Monnet
2021-10-06 18:21   ` Andrii Nakryiko
2021-10-03 19:22 ` [PATCH bpf-next v3 06/10] bpf: iterators: " Quentin Monnet
2021-10-03 19:22 ` [PATCH bpf-next v3 07/10] samples/bpf: " Quentin Monnet
2021-10-06 18:23   ` Andrii Nakryiko
2021-10-03 19:22 ` [PATCH bpf-next v3 08/10] samples/bpf: update .gitignore Quentin Monnet
2021-10-06 18:24   ` Andrii Nakryiko
2021-10-06 18:25     ` Andrii Nakryiko
2021-10-03 19:22 ` [PATCH bpf-next v3 09/10] selftests/bpf: better clean up for runqslower in test_bpftool_build.sh Quentin Monnet
2021-10-03 19:22 ` [PATCH bpf-next v3 10/10] tools: bpftool: add install-bin target to install binary only Quentin Monnet
2021-10-06 18:28 ` [PATCH bpf-next v3 00/10] install libbpf headers when using the library Andrii Nakryiko
2021-10-07 19:43   ` Quentin Monnet
2021-10-07 21:24     ` Andrii Nakryiko [this message]

Reply instructions:

You may reply publicly 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='CAEf4BzaQf1tXWpxFZ=2apFZrF-8KM81=ke7W+4Y1JUUTBqDc+g@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    --cc=quentin@isovalent.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).