Date:   Mon, 11 Oct 2021 08:46:24 +0200
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Quentin Monnet <quentin@...valent.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next v4 00/12] install libbpf headers when using the library

On Sat, Oct 9, 2021 at 11:03 PM Quentin Monnet <quentin@...valent.com> wrote:
>
> On Fri, 8 Oct 2021 at 20:13, Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
>
> > Tons of ungrateful work, thank you! Applied to bpf-next.
> >
> > I did a few clean ups (from my POV), see comments on relevant patches.
>
> Thanks for that. I don't mind the clean ups. There are several of them
> I considered before sending but wasn't sure about, so it's a good
> thing that you did it :).
>
> > Also in a bunch of Makefiles I've moved `| $(LIBBPF_OUTPUT)` to the
> > same line if the line wasn't overly long. 80 characters is not a law,
> > and I preferred single-line Makefile target definitions, if possible.
>
> No particular preference on my side, so OK.
>
> >
> > There is one problem in bpftool's Makefile, but it works with a
> > limited case of single file today. Please follow up with a proper fix.
>
> Right, good catch. I'm sending the fix.

thanks

>
> >
> > Btw, running make in bpftool's directory, I'm getting:
> >
> > make[1]: Entering directory '/data/users/andriin/linux/tools/lib/bpf'
> > make[1]: Entering directory '/data/users/andriin/linux/tools/lib/bpf'
> > make[1]: Nothing to be done for 'install_headers'.
> > make[1]: Leaving directory '/data/users/andriin/linux/tools/lib/bpf'
> > make[1]: Leaving directory '/data/users/andriin/linux/tools/lib/bpf'
> >
> > Not sure how useful those are, might be better to disable that.
>
> I had a look for bpftool, this is because we always descend into
> libbpf's directory (FORCE target). Removing this FORCE target as I did
> in samples/bpf/ avoids the descent and clears the output. I'll send a
> patch.

There is a way to prevent make from logging these enter/leave
messages, which will solve a similar problem discussed below.

>
> >
> > When running libbpf's make, we constantly getting this annoying warning:
> >
> > Warning: Kernel ABI header at 'tools/include/uapi/linux/netlink.h'
> > differs from latest version at 'include/uapi/linux/netlink.h'
> > Warning: Kernel ABI header at 'tools/include/uapi/linux/if_link.h'
> > differs from latest version at 'include/uapi/linux/if_link.h'
> >
> > If you will get a chance, maybe you can get rid of that as well? I
> > don't think we need to stay up to date with netlink.h and if_link.h,
> > so this seems like just a noise.
>
> I can look into that. Are you sure you want the warnings removed? Or
> would it be cleaner to simply update the headers?

Yeah, let's remove checks for those headers. We don't need to keep
them up to date, if there will be new features we need to use from
libbpf, we can update, if it's not already up-to-date.

>
> >
> > There was also
> >
> > make[4]: Nothing to be done for 'install_headers'.
> >
> > when building the kernel. It probably is coming from either
> > bpf_preload or iterators, but maybe also resolve_btfids, I didn't try
> > to narrow this down. Also seems like a noise, tbh. There are similar
> > useless notifications when building selftests/bpf. If it doesn't take
> > too much time to clean all that up, I'd greatly appreciate that!
>
> I haven't looked into it yet, but I can do as a follow-up. I'll post
> the patches for bpftool first because I prefer to submit the fix for
> bpftool's Makefile as soon as possible, and will look at this next.

sure. See also above about just silencing these somewhat useless
messages (it's some make variable or something like that, don't
remember)

>
> Thanks,
> Quentin

Powered by blists - more mailing lists