On Thu, Feb 20, 2020 at 05:41:51PM +0000, Bird, Tim wrote: > > So - do the BPF developers add new instructions to the virtual machine, that then > have to be added to both the compiler and the executor (VM implementation)? Right. New instructions are added to the kernel and llvm at the same time. The kernel and llvm release cadence and process are different which complicates it for us. > It sounds like the compiler support and executor support is done in concert, and > that patches are at least accepted upstream (but possibly are not yet available in > a compiler release) for the compiler side. What about the Linux kernel side? Is the > support for a new instruction only in non-released kernels (say, in the BPF development > tree), or could it potentially be included in a released kernel, before the compiler > with matching support is released? What would happen if a bug was found, and > compiler support for the instruction was delayed? As with all chicken-and-egg problems the feature has to land in one of the repos first. That was one of the reasons llvm community switched to mono repo to avoid clang vs llvm conflicts. The kernel and llvm are not going to be in a single repo, so we have to orchestrate the landing. Most of the time it's easy, because we maintain both kernel and llvm components. But in some cases it's very difficult. For example we've delayed landing kernel and libbpf patches by about six month, since we couldn't get an agreement on how the feature has to be implemented in clang. > I suppose that this would only > mean that the executor supported an instruction that never appeared in a compiled > BPF program? Is that right? The answer is yes. It is the case that the kernel supports certain bpf instructions, but llvm doesn't know how to emit them. But it has nothing to do with landing of features and release cadence.
