From: Jiri Olsa <jolsa@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Yonghong Song <yhs@fb.com>, Martin KaFai Lau <kafai@fb.com>,
David Miller <davem@redhat.com>,
John Fastabend <john.fastabend@gmail.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Wenbo Zhang <ethercflow@gmail.com>,
KP Singh <kpsingh@chromium.org>, Andrii Nakryiko <andriin@fb.com>,
Brendan Gregg <bgregg@netflix.com>,
Florent Revest <revest@chromium.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 6/9] bpf: Compile bpfwl tool at kernel compilation start
Date: Fri, 15 May 2020 16:57:52 +0200 [thread overview]
Message-ID: <20200515145752.GC3565839@krava> (raw)
In-Reply-To: <CAEf4BzYQyWAGtJtv=fvS3PRXjL66L0OJdjGf1t92a65S9pJQvg@mail.gmail.com>
On Thu, May 14, 2020 at 03:38:57PM -0700, Andrii Nakryiko wrote:
> On Wed, May 6, 2020 at 6:31 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > The bpfwl tool will be used during the vmlinux linking,
> > so it's necessary it's ready.
> >
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> > Makefile | 21 +++++++++++++++++----
> > tools/Makefile | 3 +++
> > tools/bpf/Makefile | 5 ++++-
> > 3 files changed, 24 insertions(+), 5 deletions(-)
> >
>
> [...]
>
> >
> > +prepare-bpfwl: $(bpfwl_target)
> > +ifeq ($(SKIP_BTF_WHITELIST_GENERATION),1)
> > + @echo "warning: Cannot use BTF whitelist checks, please install libelf-dev, libelf-devel or elfutils-libelf-devel" >&2
> > +endif
>
> When we added BTF dedup and generation first time, we also made pahole
> unavailability or any error during deduplication process an error. It
> actually was very confusing to users and they often missed that BTF
> generation didn't happen, but they would notice it only at runtime
> (after a confusing debugging session).
>
> So I wonder if it's better to make this an error instead? Just guard
> whitelist generation on whether CONFIG_DEBUG_INFO_BTF is enabled or
> not?
ok, makes sense.. I'll let it fail if there's CONFIG_DEBUG_INFO_BTF
enabled and we'are missing libelf
>
> > # Generate some files
> > # ---------------------------------------------------------------------------
> >
> > diff --git a/tools/Makefile b/tools/Makefile
> > index bd778812e915..85af6ebbce91 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -67,6 +67,9 @@ cpupower: FORCE
> > cgroup firewire hv guest bootconfig spi usb virtio vm bpf iio gpio objtool leds wmi pci firmware debugging: FORCE
> > $(call descend,$@)
> >
> > +bpf/%: FORCE
> > + $(call descend,$@)
> > +
> > liblockdep: FORCE
> > $(call descend,lib/lockdep)
> >
> > diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
> > index f897eeeb0b4f..d4ea2b5a2e58 100644
> > --- a/tools/bpf/Makefile
> > +++ b/tools/bpf/Makefile
> > @@ -124,5 +124,8 @@ runqslower_install:
> > runqslower_clean:
> > $(call descend,runqslower,clean)
> >
> > +bpfwl:
> > + $(call descend,bpfwl)
> > +
> > .PHONY: all install clean bpftool bpftool_install bpftool_clean \
> > - runqslower runqslower_install runqslower_clean
> > + runqslower runqslower_install runqslower_clean bpfwl
>
> what about install/clean subcommands? At least clean seems like a good idea?
not sure about install, does not seem necessary for this tool,
but I'll add propagation of clean (it's defined in bpfwl already)
thanks,
jirka
next prev parent reply other threads:[~2020-05-15 14:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 13:29 [RFCv2 0/9] bpf: Add d_path helper Jiri Olsa
2020-05-06 13:29 ` [PATCH 1/9] " Jiri Olsa
2020-05-14 22:06 ` Andrii Nakryiko
2020-05-15 14:59 ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 2/9] bpf: Add d_path whitelist Jiri Olsa
2020-05-06 13:29 ` [PATCH 3/9] bpf: Add bpfwl tool to construct bpf whitelists Jiri Olsa
2020-05-14 22:20 ` Andrii Nakryiko
2020-05-15 14:58 ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 4/9] bpf: Allow nested BTF object to be refferenced by BTF object + offset Jiri Olsa
2020-05-14 22:32 ` Andrii Nakryiko
2020-05-06 13:29 ` [PATCH 5/9] bpf: Add support to check on BTF id whitelist for d_path helper Jiri Olsa
2020-05-06 13:29 ` [PATCH 6/9] bpf: Compile bpfwl tool at kernel compilation start Jiri Olsa
2020-05-14 22:38 ` Andrii Nakryiko
2020-05-15 14:57 ` Jiri Olsa [this message]
2020-05-06 13:29 ` [PATCH 7/9] bpf: Compile the BTF id whitelist data in vmlinux Jiri Olsa
2020-05-13 18:29 ` Alexei Starovoitov
2020-05-14 8:05 ` Jiri Olsa
2020-05-14 22:46 ` Andrii Nakryiko
2020-05-15 14:57 ` Jiri Olsa
2020-05-28 17:23 ` Jiri Olsa
2020-05-29 20:48 ` Andrii Nakryiko
2020-05-31 15:10 ` Jiri Olsa
2020-06-01 19:06 ` Andrii Nakryiko
2020-06-02 8:16 ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 8/9] selftests/bpf: Add test for d_path helper Jiri Olsa
2020-05-14 22:48 ` Andrii Nakryiko
2020-05-15 14:57 ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 9/9] selftests/bpf: Add verifier " Jiri Olsa
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=20200515145752.GC3565839@krava \
--to=jolsa@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bgregg@netflix.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@redhat.com \
--cc=ethercflow@gmail.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.org \
--cc=netdev@vger.kernel.org \
--cc=revest@chromium.org \
--cc=viro@zeniv.linux.org.uk \
--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
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).