From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
netdev@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH bpf] libbpf: define BTF_KIND_* constants in btf.h to avoid compilation errors
Date: Tue, 18 Jan 2022 12:35:28 -0300 [thread overview]
Message-ID: <YebeQKsIDDaBMtpW@kernel.org> (raw)
In-Reply-To: <20220118141327.34231-1-toke@redhat.com>
Em Tue, Jan 18, 2022 at 03:13:27PM +0100, Toke Høiland-Jørgensen escreveu:
> The btf.h header included with libbpf contains inline helper functions to
> check for various BTF kinds. These helpers directly reference the
> BTF_KIND_* constants defined in the kernel header, and because the header
> file is included in user applications, this happens in the user application
> compile units.
>
> This presents a problem if a user application is compiled on a system with
> older kernel headers because the constants are not available. To avoid
> this, add #defines of the constants directly in btf.h before using them.
>
> Since the kernel header moved to an enum for BTF_KIND_*, the #defines can
> shadow the enum values without any errors, so we only need #ifndef guards
> for the constants that predates the conversion to enum. We group these so
> there's only one guard for groups of values that were added together.
>
> [0] Closes: https://github.com/libbpf/libbpf/issues/436
The coexistence of enums with the defines (in turn #ifndef guarded) as
something I hadn't considered, clever.
Should fix lots of build errors in my test containers :-)
FWIW:
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> Fixes: 223f903e9c83 ("bpf: Rename BTF_KIND_TAG to BTF_KIND_DECL_TAG")
> Fixes: 5b84bd10363e ("libbpf: Add support for BTF_KIND_TAG")
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> ---
> tools/lib/bpf/btf.h | 22 +++++++++++++++++++++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
> index 061839f04525..51862fdee850 100644
> --- a/tools/lib/bpf/btf.h
> +++ b/tools/lib/bpf/btf.h
> @@ -375,8 +375,28 @@ btf_dump__dump_type_data(struct btf_dump *d, __u32 id,
> const struct btf_dump_type_data_opts *opts);
>
> /*
> - * A set of helpers for easier BTF types handling
> + * A set of helpers for easier BTF types handling.
> + *
> + * The inline functions below rely on constants from the kernel headers which
> + * may not be available for applications including this header file. To avoid
> + * compilation errors, we define all the constants here that were added after
> + * the initial introduction of the BTF_KIND* constants.
> */
> +#ifndef BTF_KIND_FUNC
> +#define BTF_KIND_FUNC 12 /* Function */
> +#define BTF_KIND_FUNC_PROTO 13 /* Function Proto */
> +#endif
> +#ifndef BTF_KIND_VAR
> +#define BTF_KIND_VAR 14 /* Variable */
> +#define BTF_KIND_DATASEC 15 /* Section */
> +#endif
> +#ifndef BTF_KIND_FLOAT
> +#define BTF_KIND_FLOAT 16 /* Floating point */
> +#endif
> +/* The kernel header switched to enums, so these two were never #defined */
> +#define BTF_KIND_DECL_TAG 17 /* Decl Tag */
> +#define BTF_KIND_TYPE_TAG 18 /* Type Tag */
> +
> static inline __u16 btf_kind(const struct btf_type *t)
> {
> return BTF_INFO_KIND(t->info);
> --
> 2.34.1
--
- Arnaldo
next prev parent reply other threads:[~2022-01-18 15:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-18 14:13 [PATCH bpf] libbpf: define BTF_KIND_* constants in btf.h to avoid compilation errors Toke Høiland-Jørgensen
2022-01-18 15:35 ` Arnaldo Carvalho de Melo [this message]
2022-01-18 16:17 ` Toke Høiland-Jørgensen
2022-01-19 4:00 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YebeQKsIDDaBMtpW@kernel.org \
--to=acme@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=toke@redhat.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).