For special type maps (e.g. devmap and cpumap) the map-value data-layout is
a configuration interface. This is uapi that can only be tail extended.
Thus, new members (and thus features) can only be added to the end of this
structure, and the kernel uses the map->value_size from userspace to
determine feature set 'version'.
For this kind of uapi to be extensible and backward compatible, is it common
that new members/fields (that represent a new feature) in the struct are
initialized as zero, which indicate that the feature isn't used. This makes
it possible to write userspace applications that are unaware of new kernel
features, but just include latest uapi headers, zero-init struct and
populate features it knows about.
The recent extension of devmap with a bpf_prog.fd requires end-user to
supply the file-descriptor value minus-1 to communicate that the features
isn't used. This isn't compatible with the described kABI extension model.
V2: Drop patch-1 that changed BPF-syscall to start at file-descriptor 1
---
Jesper Dangaard Brouer (2):
bpf: devmap adjust uapi for attach bpf program
bpf: selftests and tools use struct bpf_devmap_val from uapi
include/uapi/linux/bpf.h | 13 +++++++++++++
kernel/bpf/devmap.c | 17 ++++-------------
tools/include/uapi/linux/bpf.h | 13 +++++++++++++
.../selftests/bpf/prog_tests/xdp_devmap_attach.c | 8 --------
.../selftests/bpf/progs/test_xdp_devmap_helpers.c | 2 +-
.../bpf/progs/test_xdp_with_devmap_helpers.c | 3 +--
6 files changed, 32 insertions(+), 24 deletions(-)
--
