All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.