On Sat, Jul 29, 2023 at 9:54 PM Jose E. Marchesi <jose.marchesi@xxxxxxxxxx> wrote: > > The individual flags... I am not sure, other arches have them, but maybe > having them in BPF doesn't make much sense and it is not worth the extra > complication and wasted bits in e_flags. How realistic is to expect > that some kernel may support a particular version of the BPF ISA, and > also have support for some particular instruction from a later ISA as > the result of a backport or something? Not for me to judge... I was > already bitten by my utter ignorance on kernel business when I added > that silly useless -mkernel=VERSION option to GCC 8-) > > What I am pretty sure is that we will need something like EF_BPF_CPUVER > if we are ever gonna support relaxation in any linker external to > libbpf, and also to detect (and error/warn) when several objects with > different BPF versions are linked together. Ok. Let's start with EF_BPF_CPUVER 0xF and not waste bits on individual instructions, as you said. When kernel backports are done the patches are sent together. It wouldn't be wise to backport SDIV without JMP32, for example. git history will get screwed up and further backports will be a pain. The risk of untested combinations increases, etc. I think it's safe to assume that a given kernel will support either v3 or v4. The kernel version doesn't matter, of course :)
