On 9/2/20 11:17 PM, Jose E. Marchesi wrote:
As such, the property of being verifiable is irrelevant.
No. It's a fundamental property of BPF.
If it's not verifiable it's not BPF.
Sure.
It's not xBPF either.
Heh, beg to differ :)
Please call it something else and don't confuse people that your ISA
has any overlap with BPF. It doesn't. It's not verifiable.
Nonsense. xBPF has as much overlap with BPF as it can have: around 99%.
The purpose of having the e_flag is to avoid confusion, not to increase
it. xBPF objects are mainly used to test the GCC BPF backend (and other
purposes we have in mind, like ease the debugging of BPF programs) but
we want to eliminate the chance of these objects to be confused with
legit BPF files, and used as such.
I fully agree with Alexei. Looking at [0], if some of these extensions are
useful and help/optimize code generation, why not add them to the BPF runtime
in the kernel so they can be properly used in general for code generation
from gcc/llvm in BPF backend? xBPF would indeed be highly confusing if it cannot
be used from the runtime (unless these are properly integrated into the kernel,
verified and thus become a fixed part of eBPF ISA).
[0] https://linuxplumbersconf.org/event/7/contributions/724/attachments/636/1166/bpf.pdf
