[<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