- 390comments
- 85comments
- 170comments
- 139comments
- 54comments
- 201comments
- 13comments
- 36comments
- 5comments
- 2comments
- 27comments
- 2comments
- 19comments
- 42comments
- 25comments
- 317comments
- 62comments
- 35comments
- 107comments
- 181comments
- 350comments
- 145comments
- 43comments
- —discuss
- 37comments
- 6comments
- —discuss
- 22comments
- 108comments
- 51comments
* https://datatracker.ietf.org/doc/html/rfc9669
* https://en.wikipedia.org/wiki/EBPF
* https://en.wikipedia.org/wiki/Berkeley_Packet_Filter
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
Somewhat related:
* https://en.wikipedia.org/wiki/P4_(programming_language)
Nice... timing to get that number.
Kind of close to ISO 9660 so doubly easy to remember.
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?