All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Delyan Kratunov <delyank@fb.com>
Cc: "daniel@iogearbox.net" <daniel@iogearbox.net>,
	"ast@kernel.org" <ast@kernel.org>,
	"andrii@kernel.org" <andrii@kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next 2/4] bpftool: add support for subskeletons
Date: Wed, 9 Mar 2022 16:38:32 -0800	[thread overview]
Message-ID: <CAEf4BzZPXAj11LsFD8rOchHSjykGJNoWsNgALbHkeqXPPU-LOA@mail.gmail.com> (raw)
In-Reply-To: <8d80bcf5802fc707e0f8a31812625d717f133300.camel@fb.com>

On Wed, Mar 9, 2022 at 4:10 PM Delyan Kratunov <delyank@fb.com> wrote:
>
> Sorry, missed this question originally.
>
> On Fri, 2022-03-04 at 11:29 -0800, Andrii Nakryiko wrote:
> > Split BTF added on top makes it a bit more
> > tolerable (though there is still a bunch of unnecessary complexity and
> > overhead just for that pesky asterisk).
> >
> > Another alternative would be:
> >
> > typeof(char[123]) *my_ptr;
> >
> > This can be done without generating extra BTF. For complex types it's
> > actually even easier to parse, tbh. I initially didn't like it, but
> > now I'm thinking maybe for arrays and func_protos we should do just
> > this? WDYT?
>
> typeof is _technically_ not standard C (I think it'll make it into C23). GCC and
> Clang do both support it but I would guess we'd want the generated userspace
> code to be compatible with as many toolchains and configurations as possible?
> (e.g. people using c99 instead of gnu99)

that ship has sailed, I'm afraid. btf.h and xsk.h (I'm not even
talking about BPF-side headers) both use typeof()

>
> Beyond that, I feel that any complexity saved by the typeof is lost in special-
> casing arrays and function prototypes when the current code is uniform across
> all types.
>
> If you insist, I can go down this path but I'm not super enthusiastic about it
> (and it's harder to read on top of everything).

I can tell you are not :)

I do think that typeof() makes it much easier to follow complicated
cases. Just look at the example below:

static int blah_fn(int x, int y) { return x + y; }

struct S {
        typeof(char[24]) *my_ptr1;
        char (*my_ptr2)[24];

        int (**my_func1)(int, int);
        typeof(int (*)(int, int)) *my_func2;
};


int main() {
        static struct S s;
        char blah[24];
        int (*fptr)(int, int);

        s.my_ptr1 = &blah;
        s.my_ptr2 = &blah;

        s.my_func1 = &fptr;
        s.my_func2 = &fptr;

        return 0;
}


Which one is easier to follow, my_ptr1 or my_ptr2? func pointer is a
bit more hypothetical (hard to come up with realistic BPF program that
would need func pointer type as global variable type), but I still did
it for completeness.


So it's not like I'm dead set against this split BTF approach, I just
do really think that array variable case is better with typeof().

>
> -- Delyan

      reply	other threads:[~2022-03-10  0:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-02  2:48 [PATCH bpf-next 0/4] Subskeleton support for BPF libraries Delyan Kratunov
2022-03-02  2:48 ` [PATCH bpf-next 3/4] libbpf: add subskeleton scaffolding Delyan Kratunov
2022-03-02 21:43   ` Daniel Borkmann
2022-03-03  0:20     ` Delyan Kratunov
2022-03-03  0:28       ` Andrii Nakryiko
2022-03-03  0:44         ` Delyan Kratunov
2022-03-03  4:33   ` Andrii Nakryiko
2022-03-03  4:34     ` Andrii Nakryiko
2022-03-03 19:09       ` Delyan Kratunov
2022-03-04 19:40         ` Andrii Nakryiko
2022-03-02  2:48 ` [PATCH bpf-next 4/4] selftests/bpf: test subskeleton functionality Delyan Kratunov
2022-03-02 22:30   ` Alexei Starovoitov
2022-03-03  0:06     ` Delyan Kratunov
2022-03-03  4:58   ` Andrii Nakryiko
2022-03-02  2:48 ` [PATCH bpf-next 1/4] libbpf: expose map elf section name Delyan Kratunov
2022-03-03  1:13   ` Andrii Nakryiko
2022-03-03 18:19     ` Delyan Kratunov
2022-03-02  2:48 ` [PATCH bpf-next 2/4] bpftool: add support for subskeletons Delyan Kratunov
2022-03-03  1:46   ` Andrii Nakryiko
2022-03-03 18:57     ` Delyan Kratunov
2022-03-03 20:54       ` Delyan Kratunov
2022-03-04 19:29         ` Andrii Nakryiko
2022-03-04 19:29       ` Andrii Nakryiko
2022-03-10  0:09         ` Delyan Kratunov
2022-03-10  0:38           ` Andrii Nakryiko [this message]

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=CAEf4BzZPXAj11LsFD8rOchHSjykGJNoWsNgALbHkeqXPPU-LOA@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=delyank@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.