All of lore.kernel.org
 help / color / mirror / Atom feed
From: Delyan Kratunov <delyank@fb.com>
To: "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: [PATCH bpf-next 0/4] Subskeleton support for BPF libraries
Date: Wed, 2 Mar 2022 02:48:50 +0000	[thread overview]
Message-ID: <cover.1646188795.git.delyank@fb.com> (raw)

In the quest for ever more modularity, a new need has arisen - the ability to
access data associated with a BPF library from a corresponding userspace library.
The catch is that we don't want the userspace library to know about the structure of the
final BPF object that the BPF library is linked into.

In pursuit of this modularity, this patch series introduces *subskeletons.*
Subskeletons are similar in use and design to skeletons with a couple of differences:

1. The generated storage types do not rely on contiguous storage for the library's
variables because they may be interspersed randomly throughout the final BPF object's sections.

2. Subskeletons do not own objects and instead require a loaded bpf_object* to
be passed at runtime in order to be initialized. By extension, symbols are resolved at
runtime by parsing the final object's BTF. This has the interesting effect that the same
userspace code can interoperate with the library BPF code *linked into different final objects.*

3. Currently, only globals are supported though the codegen can be extended to support
non-owning pointers to maps, progs, links, etc.

Areas that are RFC/TODO:
* AFAICT, the ELF section names are the only way to find the correct maps in the final
linked object. As a result, I've added bpf_map__section_name so bpftool can use the section
names in the codegen. Do let me know if there's a better design I'm missing.

* The bpf_object__{open,destroy}_subskeleton approach mirrors the corresponding skeleton
support functionality. Do let me know if there's anything that needs to exist in it to ensure
forward compatibility. (Unfortunately, I don't see any way for subskeletons to work with older
libbpf versions, so I'd rather introduce all the new APIs they may need in a single version.)


Delyan Kratunov (4):
  libbpf: expose map elf section name
  bpftool: add support for subskeletons
  libbpf: add subskeleton scaffolding
  selftests/bpf: test subskeleton functionality

 tools/bpf/bpftool/gen.c                       | 322 +++++++++++++++++-
 tools/lib/bpf/libbpf.c                        |  84 +++++
 tools/lib/bpf/libbpf.h                        |  23 ++
 tools/lib/bpf/libbpf.map                      |   7 +
 tools/lib/bpf/libbpf_version.h                |   2 +-
 tools/testing/selftests/bpf/Makefile          |  18 +-
 .../selftests/bpf/prog_tests/subskeleton.c    |  38 +++
 .../bpf/prog_tests/subskeleton_lib.c          |  29 ++
 .../selftests/bpf/progs/test_subskeleton.c    |  20 ++
 .../bpf/progs/test_subskeleton_lib.c          |  22 ++
 10 files changed, 553 insertions(+), 12 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/subskeleton.c
 create mode 100644 tools/testing/selftests/bpf/prog_tests/subskeleton_lib.c
 create mode 100644 tools/testing/selftests/bpf/progs/test_subskeleton.c
 create mode 100644 tools/testing/selftests/bpf/progs/test_subskeleton_lib.c

--
2.34.1

             reply	other threads:[~2022-03-02  2:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-02  2:48 Delyan Kratunov [this message]
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

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=cover.1646188795.git.delyank@fb.com \
    --to=delyank@fb.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    /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.