[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9ca4b5dd-20be-79ac-52eb-a19c0c82280f@iogearbox.net>
Date: Fri, 26 Apr 2024 17:54:28 +0200
From: Daniel Borkmann <daniel@...earbox.net>
To: Dmitrii Bundin <dmitrii.bundin.a@...il.com>, olsajiri@...il.com
Cc: andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org, dxu@...uu.xyz,
eddyz87@...il.com, haoluo@...gle.com, john.fastabend@...il.com,
khazhy@...omium.org, kpsingh@...nel.org, linux-kernel@...r.kernel.org,
martin.lau@...ux.dev, ncopa@...inelinux.org, ndesaulniers@...gle.com,
sdf@...gle.com, song@...nel.org, vmalik@...hat.com, yonghong.song@...ux.dev
Subject: Re: [PATCH bpf-next v3] bpf: btf: include linux/types.h for u32
On 4/20/24 6:24 AM, Dmitrii Bundin wrote:
> Inclusion of the header linux/btf_ids.h relies on indirect inclusion of
> the header linux/types.h. Including it directly on the top level helps
> to avoid potential problems if linux/types.h hasn't been included
> before.
>
> The main motiviation to introduce this it is to avoid similar problems that
nit: spelling
> was shown up in the bpf tool where GNU libc indirectly pulls
> linux/types.h causing compile error of the form:
>
> error: unknown type name 'u32'
> u32 cnt;
> ^~~
>
> The bpf tool compile error was fixed at 62248b22d01e96a4d669cde0d7005bd51ebf9e76
>
> Fixes: 9707ac4fe2f5 ("tools/resolve_btfids: Refactor set sorting with types from btf_ids.h")
>
> Signed-off-by: Dmitrii Bundin <dmitrii.bundin.a@...il.com>
> ---
>
> Changes in v2: Add bpf-next to the subject
> Changes in v3: Add Fixes tag and bpf tool commit reference
>
> include/linux/btf_ids.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
> index e24aabfe8ecc..c0e3e1426a82 100644
> --- a/include/linux/btf_ids.h
> +++ b/include/linux/btf_ids.h
> @@ -3,6 +3,8 @@
> #ifndef _LINUX_BTF_IDS_H
> #define _LINUX_BTF_IDS_H
>
> +#include <linux/types.h> /* for u32 */
> +
> struct btf_id_set {
> u32 cnt;
> u32 ids[];
>
Lgtm, not sure if its worth it but also doesn't hurt and aligns the header
from tooling a bit closer to the kernel one. Just to clarify, this does not
fix a concrete issue today, so small 'cleanup' rather than 'fix'.
Thanks,
Daniel
Powered by blists - more mailing lists