BPF Backend Merged Into LLVM To Make Use Of New Kernel Functionality
The newest LLVM back-end in the mainline code is for supporting BPF, the "universal in-kernel virtual machine" present in the latest releases of the Linux kernel.
For those not familiar with BPF, there's a basic overview of the Berkeley Packet Filter via Wikipedia and the eBPF system call man page. Per the name, BPF was originally designed for packet-filtering but has been extended out of the Linux kernel networking subsystem to handle other functionality as it's very flexible and can be adapted to other situations. This non-networking support is called eBPF, short for the extended BPF. With eBPF, it's aimed at being a universal in-kernel virtual machine. Over 2014, BPF's in-kernel support improved a lot -- and eBPF appears to be in good shape since Linux 3.18 when the bpf syscall was added -- and is now of interest to compiler developers.
The BPF LLVM back-end is needed for emitting the instructions to actually use the extended BPF instruction set so that it can be consumed by the kernel. Outside of the networking world, eBPF is viewed as being useful to tracepoints. The BPF LLVM back-end is self-described as:
For those not familiar with BPF, there's a basic overview of the Berkeley Packet Filter via Wikipedia and the eBPF system call man page. Per the name, BPF was originally designed for packet-filtering but has been extended out of the Linux kernel networking subsystem to handle other functionality as it's very flexible and can be adapted to other situations. This non-networking support is called eBPF, short for the extended BPF. With eBPF, it's aimed at being a universal in-kernel virtual machine. Over 2014, BPF's in-kernel support improved a lot -- and eBPF appears to be in good shape since Linux 3.18 when the bpf syscall was added -- and is now of interest to compiler developers.
The BPF LLVM back-end is needed for emitting the instructions to actually use the extended BPF instruction set so that it can be consumed by the kernel. Outside of the networking world, eBPF is viewed as being useful to tracepoints. The BPF LLVM back-end is self-described as:
It's a very small and simple backend. There is no support for global variables, arbitrary function calls, floating point, varargs, exceptions, indirect jumps, arbitrary pointer arithmetic, alloca, etc. From C front-end point of view it's very restricted. It's done on purpose, since kernel rejects all programs that it cannot prove safe. It rejects programs with loops and with memory accesses via arbitrary pointers. When kernel accepts the program it is guaranteed that program will terminate and will not crash the kernel.The BPF LLVM back-end was merged today in the LLVM Git/SVN code-base and thus will be part of the LLVM 3.7 release. This work was done by Alexei Starovoitov, the same developer doing much of the in-kernel BPF work.
This patch implements all 'must have' bits. There are several things on TODO list, so this is not the end of development.
Add A Comment