[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <80728495-e1fe-21bb-9814-6251648f8359@iogearbox.net>
Date: Mon, 25 Apr 2022 23:35:41 +0200
From: Daniel Borkmann <daniel@...earbox.net>
To: Dominique Martinet <asmadeus@...ewreck.org>, bpf@...r.kernel.org
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
KP Singh <kpsingh@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
Yonghong Song <yhs@...com>, Song Liu <songliubraving@...com>,
Martin KaFai Lau <kafai@...com>,
Andrii Nakryiko <andrii@...nel.org>,
Alexei Starovoitov <ast@...nel.org>
Subject: Re: [PATCH 1/4] tools/bpf/runqslower: musl compat: explicitly link
with libargp if found
On 4/24/22 8:58 AM, Dominique Martinet wrote:
> Dominique Martinet wrote on Sun, Apr 24, 2022 at 02:10:19PM +0900:
>> After having done this work I noticed runqslower is not actually
>> installed, so ideally instead of all of this it'd make more sense to
>> just not build it: would it make sense to take it out of the defaults
>> build targets?
>> I could just directly build the appropriate targets from tools/bpf
>> directory with 'make bpftool bpf_dbg bpf_asm bpf_jit_disasm', but
>> ideally I'd like to keep alpine's build script way of calling make from
>> the tools parent directory, and 'make bpf' there is all or nothing.
>
> Well, it turns out runqslower doesn't build if the current kernel or
> vmlinux in tree don't have BTF enabled, so the current alpine builder
> can't build it.
>
> I've dropped this patch from my alpine MR[1] and built things directly
> with make bpftool etc as suggested above, so my suggestion to make it
> more easily buildable that way is probably the way to go?
> [1] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33554
Thanks for looking into this, Dominique! I slightly massaged patch 3 & 4
and applied it to bpf-next tree.
I don't really mind about patch 1 & 2, though out of tools/bpf/ the only
one you /really/ might want to package is bpftool. The other tools are on
the legacy side of things and JIT disasm you can also get via bpftool anyway.
Given this is not covered by BPF CI, are you planning to regularly check
for musl compatibility before a new kernel is cut?
Thanks,
Daniel
Powered by blists - more mailing lists