tree 000d48d76dee823311370b3e2d553882ca954a3a
parent 996684608c49b4c0b01a0220f62de30b70bdbb6b
author Maciej Żenczykowski <maze@google.com> 1657198917 -0700
committer Maciej Żenczykowski <maze@google.com> 1657216818 +0000

BpfLoader v0.25 - add support for obj@ver.o

This allows for 2 different versions of obj.o to be
shipped simultaneously (via mainline module),
with different bpfloader version limitations.

For example a obj.o for bpfloader < 0.25 and a
obj@25.o for bpfloader 0.25+.  These can provide
for different implementations of maps/programs,
while still being pinned into the same ultimate
destination in /sys/fs/bpf/.../{map,prog}_obj_...
so as to not require special selection of appropriate
program/map path names in higher level code
(at least for common functionality).

When using this functionality one does have to be
careful to not end up with unintentional duplication
(ie. an obj@1.o and obj@2.o that both load on bpfloader
version X), and to make sure that the defined
bpf maps and programs with identical names
are also sufficiently identical in behaviour.

In practice it is likely that all versions of obj@ver.o
will be built from the same source code, with compilation
controlled by appropriate preprocessor conditional macros,
to hide certain parts of obj.c while building the version
for older bpfloader...

However, exactly how to use this is ultimately
left up to the future...
Multiple viable mechanisms exist:

(a) each obj@ver.o is standalone, only one should be loaded,
    bpfloader min/max version annotations would be used
    to guarantee this, making sure that programs/maps that
    exist in multiple versions of obj.o should have matching
    types and behaviours, but nothing guarantees this
    (although key/value size checks will certainly help)
(b) obj.o is baseline and always loaded,
    while obj@25.o is an extension with extra maps/programs
    and is loaded on only newer bpfloaders,
    it may have duplicate defines of shared maps
    (likely via #include of some shared header file)
    if some of the extra programs also need some of
    the data from maps from the 'older' obj.o
(c) variously complex combinations of (a) and (b) are also possible

Bug: 218408035
Test: TreeHugger, manually with offload@1.o in p/m/C
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ib60d07b18fd6617d456c2c469f8e8ed166aadffd