netdev - Re: [PATCH bpf-next v2 6/9] bpf: iterators: install libbpf headers when building

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEf4BzYm_QTq+u5tUp71+wY+JAaiUApv35tSqFUEyc81yOeUzw@mail.gmail.com>
Date:   Fri, 1 Oct 2021 16:19:59 -0700
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 v2 6/9] bpf: iterators: install libbpf headers
 when building

On Fri, Oct 1, 2021 at 4:09 AM Quentin Monnet <quentin@...valent.com> wrote:
>
> API headers from libbpf should not be accessed directly from the
> library's source directory. Instead, they should be exported with "make
> install_headers". Let's make sure that bpf/preload/iterators/Makefile
> installs the headers properly when building.
>
> Signed-off-by: Quentin Monnet <quentin@...valent.com>
> ---
>  kernel/bpf/preload/iterators/Makefile | 18 +++++++++++-------
>  1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/bpf/preload/iterators/Makefile b/kernel/bpf/preload/iterators/Makefile
> index 28fa8c1440f4..cf549dab3e20 100644
> --- a/kernel/bpf/preload/iterators/Makefile
> +++ b/kernel/bpf/preload/iterators/Makefile
> @@ -6,9 +6,11 @@ LLVM_STRIP ?= llvm-strip
>  DEFAULT_BPFTOOL := $(OUTPUT)/sbin/bpftool
>  BPFTOOL ?= $(DEFAULT_BPFTOOL)
>  LIBBPF_SRC := $(abspath ../../../../tools/lib/bpf)
> -BPFOBJ := $(OUTPUT)/libbpf.a
> -BPF_INCLUDE := $(OUTPUT)
> -INCLUDES := -I$(OUTPUT) -I$(BPF_INCLUDE) -I$(abspath ../../../../tools/lib)        \
> +LIBBPF_OUTPUT := $(abspath $(OUTPUT))/libbpf
> +LIBBPF_DESTDIR := $(LIBBPF_OUTPUT)
> +LIBBPF_INCLUDE := $(LIBBPF_DESTDIR)/include
> +BPFOBJ := $(LIBBPF_OUTPUT)/libbpf.a
> +INCLUDES := -I$(OUTPUT) -I$(LIBBPF_INCLUDE)                                   \
>         -I$(abspath ../../../../tools/include/uapi)
>  CFLAGS := -g -Wall
>
> @@ -44,13 +46,15 @@ $(OUTPUT)/iterators.bpf.o: iterators.bpf.c $(BPFOBJ) | $(OUTPUT)
>                  -c $(filter %.c,$^) -o $@ &&                                 \
>         $(LLVM_STRIP) -g $@
>
> -$(OUTPUT):
> +$(OUTPUT) $(LIBBPF_OUTPUT) $(LIBBPF_INCLUDE):
>         $(call msg,MKDIR,$@)
> -       $(Q)mkdir -p $(OUTPUT)
> +       $(Q)mkdir -p $@
>
> -$(BPFOBJ): $(wildcard $(LIBBPF_SRC)/*.[ch] $(LIBBPF_SRC)/Makefile) | $(OUTPUT)
> +$(BPFOBJ): $(wildcard $(LIBBPF_SRC)/*.[ch] $(LIBBPF_SRC)/Makefile)            \
> +          | $(LIBBPF_OUTPUT) $(LIBBPF_INCLUDE)

Would it make sense for libbpf's Makefile to create include and output
directories on its own? We wouldn't need to have these order-only
dependencies everywhere, right?

>         $(Q)$(MAKE) $(submake_extras) -C $(LIBBPF_SRC)                         \
> -                   OUTPUT=$(abspath $(dir $@))/ $(abspath $@)
> +                   OUTPUT=$(abspath $(dir $@))/ prefix=                       \
> +                   DESTDIR=$(LIBBPF_DESTDIR) $(abspath $@) install_headers
>
>  $(DEFAULT_BPFTOOL):
>         $(Q)$(MAKE) $(submake_extras) -C ../../../../tools/bpf/bpftool                        \
> --
> 2.30.2
>