The BPF instruction set architecture is now RFC 9669
lwn.netSomewhat related:
> P4 is a programming language for controlling packet forwarding planes in networking devices, such as routers and switches. In contrast to a general purpose language such as C or Python, P4 is a domain-specific language with a number of constructs optimized for network data forwarding. P4 is distributed as open-source, permissively licensed code, and is maintained by the P4 Project (formerly the P4 Language Consortium), a not-for-profit organization hosted by the Open Networking Foundation.
So… eBPF is now BPF and old BPF is now cBPF or classic bpf.
And there's wasm-bpf: https://github.com/eunomia-bpf/wasm-bpf#how-it-works
But should (browser) WASM processes cross the kernel boundary for BPF performance?
FWIW EVM/eWASM opcodes have a cost in gas/particles.
Do you think that BPF opcodes should be costed, too? Why or why not?
Are you... asking yourself? What did you decide?
Costing instructions leads to efficiency metrics, which makes it possible to incentivize efficiency.
BPF instructions could also each have an abstract relative cost with or without real value.
BPF in WASM (unfortunately without the kernel performance advantages or possible side channels) or the fwiu now-defunct eWASM might be an easier place to test the value of costed opcodes.
The [e]BPF verifier does not yet rewrite according to opcode costs of candidate programs.
"A look inside the BPF verifier [lwn]" https://news.ycombinator.com/item?id=41135478
Is this going to be like the DeviceTree standard? The kernels devs invent it, it gets an official specification/standard, but the kernel itself doesn't conform to that specification?
Nice... timing to get that number.
Kind of close to ISO 9660 so doubly easy to remember.