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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.