All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Yonghong Song <yhs@fb.com>, Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Alexei Starovoitov <ast@fb.com>, Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v2 bpf-next 1/3] bpf: switch BPF UAPI #define constants to enums
Date: Mon, 2 Mar 2020 21:48:20 +0100	[thread overview]
Message-ID: <6b5d7686-428b-5812-75c7-c9d38847f48c@iogearbox.net> (raw)
In-Reply-To: <af9e3e1e-e1e9-0462-88a4-93fd06c40957@fb.com>

On 3/2/20 7:33 PM, Yonghong Song wrote:
> On 3/2/20 10:25 AM, Andrii Nakryiko wrote:
>> On Mon, Mar 2, 2020 at 8:22 AM Yonghong Song <yhs@fb.com> wrote:
>>> On 2/29/20 10:24 PM, Andrii Nakryiko wrote:
>>>> Switch BPF UAPI constants, previously defined as #define macro, to anonymous
>>>> enum values. This preserves constants values and behavior in expressions, but
>>>> has added advantaged of being captured as part of DWARF and, subsequently, BTF
>>>> type info. Which, in turn, greatly improves usefulness of generated vmlinux.h
>>>> for BPF applications, as it will not require BPF users to copy/paste various
>>>> flags and constants, which are frequently used with BPF helpers.
>>>>
>>>> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
>>>> ---
>>>>    include/uapi/linux/bpf.h              | 272 +++++++++++++++----------
>>>>    include/uapi/linux/bpf_common.h       |  86 ++++----
>>>>    include/uapi/linux/btf.h              |  60 +++---
>>>>    tools/include/uapi/linux/bpf.h        | 274 ++++++++++++++++----------
>>>>    tools/include/uapi/linux/bpf_common.h |  86 ++++----
>>>>    tools/include/uapi/linux/btf.h        |  60 +++---
>>>>    6 files changed, 497 insertions(+), 341 deletions(-)
>>>>
>>>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>>>> index 8e98ced0963b..03e08f256bd1 100644
>>>> --- a/include/uapi/linux/bpf.h
>>>> +++ b/include/uapi/linux/bpf.h
>>>> @@ -14,34 +14,36 @@
>>>>    /* Extended instruction set based on top of classic BPF */
>>>>
>>>>    /* instruction classes */
>>>> -#define BPF_JMP32    0x06    /* jmp mode in word width */
>>>> -#define BPF_ALU64    0x07    /* alu mode in double word width */
>>>> +enum {
>>>> +     BPF_JMP32       = 0x06, /* jmp mode in word width */
>>>> +     BPF_ALU64       = 0x07, /* alu mode in double word width */
>>>
>>> Not sure whether we have uapi backward compatibility or not.

We do, after all it's uapi. I think the only expectation people might have is that
if they use custom stuff with BPF_ prefix in their own code that there could potentially
be collisions with future additions to this uapi header, but otherwise existing constructs
in their own code that rely on existing (e.g.) defines in this header must not break.

>>> One possibility is to add
>>>     #define BPF_ALU64 BPF_ALU64
>>> this way, people uses macros will continue to work.

Yep. :-/

>> This is going to be a really ugly solution, though. I wonder if it was
>> ever an expected behavior of UAPI constants to be able to do #ifdef on
>> them.

Yes, that will be quite ugly. We still would have the freedom to split the giant bpf.h
into smaller chunks e.g. under include/uapi/linux/bpf/ and perhaps trying to get some
systematic order that way. Like splitting out include/uapi/linux/bpf/insns.h where we
do this enum/define only for the insns etc. While that doesn't change the fact that this
would be needed, it at least doesn't look too random/chaotic all over the place in bpf.h.

>> Do you know any existing application that relies on those constants
>> being #defines?
> 
> I did not have enough experience to work with system level applications.
> But in linux/in.h we have
> 
> #if __UAPI_DEF_IN_IPPROTO
> /* Standard well-defined IP protocols.  */
> enum {
>    IPPROTO_IP = 0,               /* Dummy protocol for TCP               */
> #define IPPROTO_IP              IPPROTO_IP
>    IPPROTO_ICMP = 1,             /* Internet Control Message Protocol    */
> #define IPPROTO_ICMP            IPPROTO_ICMP
>    IPPROTO_IGMP = 2,             /* Internet Group Management Protocol   */
> #define IPPROTO_IGMP            IPPROTO_IGMP
>    IPPROTO_IPIP = 4,             /* IPIP tunnels (older KA9Q tunnels use 94) */
> #define IPPROTO_IPIP            IPPROTO_IPIP
>    IPPROTO_TCP = 6,              /* Transmission Control Protocol        */
> #define IPPROTO_TCP             IPPROTO_TCP
>    IPPROTO_EGP = 8,              /* Exterior Gateway Protocol            */
> #define IPPROTO_EGP             IPPROTO_EGP
>    IPPROTO_PUP = 12,             /* PUP protocol                         */
> #define IPPROTO_PUP             IPPROTO_PUP
>    IPPROTO_UDP = 17,             /* User Datagram Protocol               */
> #define IPPROTO_UDP             IPPROTO_UDP
>    IPPROTO_IDP = 22,             /* XNS IDP protocol                     */
> #define IPPROTO_IDP             IPPROTO_IDP
> 
> ...

  parent reply	other threads:[~2020-03-02 20:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-01  6:24 [PATCH v2 bpf-next 0/3] Convert BPF UAPI constants into enum values Andrii Nakryiko
2020-03-01  6:24 ` [PATCH v2 bpf-next 1/3] bpf: switch BPF UAPI #define constants to enums Andrii Nakryiko
2020-03-02 16:22   ` Yonghong Song
2020-03-02 18:25     ` Andrii Nakryiko
2020-03-02 18:33       ` Yonghong Song
2020-03-02 19:14         ` Andrii Nakryiko
2020-03-02 20:48         ` Daniel Borkmann [this message]
2020-03-02 22:37   ` Alexei Starovoitov
2020-03-02 23:14     ` Andrii Nakryiko
2020-03-01  6:24 ` [PATCH v2 bpf-next 2/3] libbpf: assume unsigned values for BTF_KIND_ENUM Andrii Nakryiko
2020-03-01  6:24 ` [PATCH v2 bpf-next 3/3] tools/runqslower: drop copy/pasted BPF_F_CURRENT_CPU definiton Andrii Nakryiko

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=6b5d7686-428b-5812-75c7-c9d38847f48c@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --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.