netdev - Re: [PATCH net-next] selftests: net: Add cross-compilation support for BPF programs

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]

Date:   Tue, 22 Nov 2022 08:47:01 +0100
From:   Anders Roxell <anders.roxell@...aro.org>
To:     Björn Töpel <bjorn@...nel.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        Björn Töpel <bjorn@...osinc.com>,
        Lina Wang <lina.wang@...iatek.com>,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next] selftests: net: Add cross-compilation support
 for BPF programs

On Mon, 21 Nov 2022 at 17:48, Björn Töpel <bjorn@...nel.org> wrote:
>
> Anders Roxell <anders.roxell@...aro.org> writes:
>
> > On Sat, 19 Nov 2022 at 18:19, Björn Töpel <bjorn@...nel.org> wrote:
> [...]
> >> Now that BPF builds are starting to show up in more places
> >> (selftests/net, and soon selftests/hid), maybe it would be cleaner to
> >> move parts of the BPF builds to lib.mk?
> >
> > Yes, since its in tc-testing too.
> > Maybe thats what we should do already now?
>
> Ok, so there's three BPF builds, in addition to selftests/bpf. Do you
> suggest moving (cross-compiled) libbpf builds (for bpf_helpers_defs.h
> generation) and some kind of clang BPF build-rule to lib.mk?

Maybe start with moving the libbpf builds, for build_helpers_defs.h generation,
and 'define get_sys_includes' into the lib.mk ?

> Or would
> you like more things there, like resolve_btfids?
>
> I guess this patch could go in regardless, and fix the build *now*, and
> do a lib.mk thing as a follow-up?

Make sense.

Reviewed-by: Anders Roxell <anders.roxell@...aro.org>

Cheers,
Anders