News for hackers. Stuff that matters.
Re:BPF for storage: an exokernel-inspired approach by nynx on Saturday March 27, 2021 @12:24PM (#26603425)
I'd prefer it to use spirv or wasm. eBPF is intentionally an extremely limited language.
Re:BPF for storage: an exokernel-inspired approach by KMag on Saturday March 27, 2021 @12:33PM (#26603490)
But trivially provable termination is really nice property if you don't want to need your hypervisor to trust every guest kernel.
Re:BPF for storage: an exokernel-inspired approach by benlwalker on Saturday March 27, 2021 @12:34PM (#26603502)
eBPF the bytecode is not particularly limited. You can parse complex formats like Arrow or Parquet even. The Linux kernel overlays a verifier on top which adds all sorts of draconian restrictions (for good reason). When people talk of eBPF they don't always mean to include the Linux verifier limitations as well. In particular, that nvmexpress working group link in the parent post does not say one way or the other.
Re:BPF for storage: an exokernel-inspired approach by nynx on Saturday March 27, 2021 @12:35PM (#26603514)
Why not use a different bytecode that is already more common, in that case?
Re:BPF for storage: an exokernel-inspired approach by monocasa on Saturday March 27, 2021 @01:21PM (#26603786)
Because ebpf is designed for verification under constrained circumstances like kernels, but allowing easy JITing that's almost a 1 to 1 translation. Stuff like not doing register allocation, being 2 address, etc.