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: <CADYN=9JDOBHEgmiWCy_k5sXLizdtRET6-G5_PdZcaOLvSp5vTA@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ