On Mon, Oct 16, 2023 at 7:03 PM Andrii Nakryiko <andrii@xxxxxxxxxx> wrote: ... > This patch set adds a basic minimum of functionality to make BPF token idea > useful and to discuss API and functionality. Currently only low-level libbpf > APIs support creating and passing BPF token around, allowing to test kernel > functionality, but for the most part is not sufficient for real-world > applications, which typically use high-level libbpf APIs based on `struct > bpf_object` type. This was done with the intent to limit the size of patch set > and concentrate on mostly kernel-side changes. All the necessary plumbing for > libbpf will be sent as a separate follow up patch set kernel support makes it > upstream. > > Another part that should happen once kernel-side BPF token is established, is > a set of conventions between applications (e.g., systemd), tools (e.g., > bpftool), and libraries (e.g., libbpf) on exposing delegatable BPF FS > instance(s) at well-defined locations to allow applications take advantage of > this in automatic fashion without explicit code changes on BPF application's > side. But I'd like to postpone this discussion to after BPF token concept > lands. In the patch set you've extended MAP_CREATE, PROG_LOAD and BTF_LOAD to accept an additional token_fd. How many more commands will need a token as a context like this? It would cause a lot of churn to support many BPF commands like this, since every command will have token_fd at a different offset in bpf_attr. This means we need to write extra code for each new command, both in kernel as well as user space. Could we pass the token in a way that is uniform across commands? Something like additional arg to the syscall or similar. Lorenz
