From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Stanislav Fomichev <sdf@fomichev.me>,
Andrii Nakryiko <andriin@fb.com>,
LKML <linux-kernel@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Networking <netdev@vger.kernel.org>,
Alexei Starovoitov <ast@fb.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH bpf-next 11/15] bpftool: add skeleton codegen command
Date: Thu, 12 Dec 2019 10:43:34 -0800 [thread overview]
Message-ID: <20191212104334.222552a1@cakuba.netronome.com> (raw)
In-Reply-To: <CAEf4BzYJHvuFbBM-xvCCsEa+Pg-bG1tprGMbCDtsbGHdv7KspA@mail.gmail.com>
On Thu, 12 Dec 2019 08:53:22 -0800, Andrii Nakryiko wrote:
> > > > Btw, how hard it would be to do this generation with a new python
> > > > script instead of bpftool? Something along the lines of
> > > > scripts/bpf_helpers_doc.py that parses BTF and spits out this C header
> > > > (shouldn't be that hard to write custom BTF parser in python, right)?
> > > >
> > >
> > > Not impossible, but harder than I'd care to deal with. I certainly
> > > don't want to re-implement a good chunk of ELF and BTF parsing (maps,
> > > progs, in addition to datasec stuff). But "it's hard to use bpftool in
> > > our build system" doesn't seem like good enough reason to do all that.
> > You can replace "our build system" with some other project you care about,
> > like systemd. They'd have the same problem with vendoring in recent enough
> > bpftool or waiting for every distro to do it. And all this work is
> > because you think that doing:
> >
> > my_obj->rodata->my_var = 123;
> >
> > Is easier / more type safe than doing:
> > int *my_var = bpf_object__rodata_lookup(obj, "my_var");
> > *my_var = 123;
>
> Your arguments are confusing me. Did I say that we shouldn't add this
> type of "dynamic" interface to variables? Or did I say that every
> single BPF application has to adopt skeleton and bpftool? I made no
> such claims and it seems like discussion is just based around where I
> have to apply my time and efforts... You think it's not useful - don't
> integrate bpftool into your build system, simple as that. Skeleton is
> used for selftests, but it's up to maintainers to decide whether to
> keep this, similar to all the BTF decisions.
Since we have two people suggesting this functionality to be a separate
tool could you please reconsider my arguments from two days ago?
There absolutely nothing this tool needs from [bpftool], no
JSON needed, no bpffs etc. It can be a separate tool like
libbpf-skel-gen or libbpf-c-skel or something, distributed with libbpf.
That way you can actually soften the backward compat. In case people
become dependent on it they can carry that little tool on their own.
I'd honestly leave the distro packaging problem for people who actually
work on that to complain about.
next prev parent reply other threads:[~2019-12-12 18:43 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 1:14 [PATCH bpf-next 00/15] Add code-generated BPF object skeleton support Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 01/15] libbpf: don't require root for bpf_object__open() Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 02/15] libbpf: add generic bpf_program__attach() Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 03/15] libbpf: move non-public APIs from libbpf.h to libbpf_internal.h Andrii Nakryiko
2019-12-10 1:33 ` Jakub Kicinski
2019-12-10 17:04 ` Andrii Nakryiko
2019-12-10 18:17 ` Jakub Kicinski
2019-12-10 18:47 ` Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 04/15] libbpf: add BPF_EMBED_OBJ macro for embedding BPF .o files Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 05/15] libbpf: expose field/var declaration emitting API internally Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 06/15] libbpf: expose BPF program's function name Andrii Nakryiko
2019-12-11 19:38 ` [Potential Spoof] " Martin Lau
2019-12-11 19:54 ` Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 07/15] libbpf: refactor global data map initialization Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 08/15] libbpf: postpone BTF ID finding for TRACING programs to load phase Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 09/15] libbpf: reduce log level of supported section names dump Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 10/15] libbpf: add experimental BPF object skeleton support Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 11/15] bpftool: add skeleton codegen command Andrii Nakryiko
2019-12-10 1:57 ` Jakub Kicinski
2019-12-10 17:11 ` Andrii Nakryiko
2019-12-10 18:05 ` Jakub Kicinski
2019-12-10 18:56 ` Andrii Nakryiko
2019-12-10 21:44 ` Stanislav Fomichev
2019-12-10 22:33 ` Andrii Nakryiko
2019-12-10 22:59 ` Stanislav Fomichev
2019-12-11 7:07 ` Andrii Nakryiko
2019-12-11 17:24 ` Stanislav Fomichev
2019-12-11 18:26 ` Andrii Nakryiko
2019-12-11 19:15 ` Stanislav Fomichev
2019-12-11 19:41 ` Andrii Nakryiko
2019-12-11 20:09 ` Stanislav Fomichev
2019-12-12 0:50 ` Andrii Nakryiko
2019-12-12 2:57 ` Stanislav Fomichev
2019-12-12 7:27 ` Andrii Nakryiko
2019-12-12 16:29 ` Stanislav Fomichev
2019-12-12 16:53 ` Andrii Nakryiko
2019-12-12 18:43 ` Jakub Kicinski [this message]
2019-12-12 18:58 ` Stanislav Fomichev
2019-12-12 19:23 ` Jakub Kicinski
2019-12-12 19:54 ` Alexei Starovoitov
2019-12-12 20:21 ` Jakub Kicinski
2019-12-12 21:28 ` Alexei Starovoitov
2019-12-12 21:59 ` Jakub Kicinski
2019-12-13 6:48 ` Andrii Nakryiko
2019-12-13 17:47 ` Jakub Kicinski
2019-12-12 21:45 ` Stanislav Fomichev
2019-12-13 6:23 ` Andrii Nakryiko
2019-12-11 22:50 ` [Potential Spoof] " Martin Lau
2019-12-16 14:16 ` Daniel Borkmann
2019-12-16 18:53 ` Andrii Nakryiko
2019-12-17 13:59 ` Daniel Borkmann
2019-12-17 15:45 ` Alexei Starovoitov
2019-12-10 1:14 ` [PATCH bpf-next 12/15] selftests/bpf: add BPF skeletons selftests and convert attach_probe.c Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 13/15] selftests/bpf: convert few more selftest to skeletons Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 14/15] selftests/bpf: add test validating data section to struct convertion layout Andrii Nakryiko
2019-12-10 1:14 ` [PATCH bpf-next 15/15] bpftool: add `gen skeleton` BASH completions Andrii Nakryiko
2019-12-11 22:55 ` [PATCH bpf-next 00/15] Add code-generated BPF object skeleton support Martin Lau
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=20191212104334.222552a1@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox