From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
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 17:17:56 +0100 [thread overview]
Message-ID: <87k0ex81cb.fsf@toke.dk> (raw)
In-Reply-To: <YebeQKsIDDaBMtpW@kernel.org>
Arnaldo Carvalho de Melo <acme@kernel.org> writes:
> 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.
Me neither - that bit was Andrii's idea :)
> Should fix lots of build errors in my test containers :-)
>
> FWIW:
>
> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Thanks!
-Toke
next prev parent reply other threads:[~2022-01-18 16:19 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
2022-01-18 16:17 ` Toke Høiland-Jørgensen [this message]
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=87k0ex81cb.fsf@toke.dk \
--to=toke@redhat.com \
--cc=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=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.