3 ms·

Is there a risk that companies could start having closed source code external to the kernel, to support devices, via this? The monolithic GPL kernel has been a

• mdaverde 4y ago
  In the same way out-of-tree kernel modules are enforced to license themselves as GPL if they intend to use a lot (if not most) of the available functionality, eBPF programs fall under the same restrictions. bpftool[0] allows you to see which programs are currently running in your system, their bpf asm instructions and whether they are GPL-compliant through `bpftool prog show`. Of course, we still need companies to actually release the source code of their eBPF programs somewhere for the promise to be fulfilled. [0] https://github.com/libbpf/bpftool https://github.com/libbpf/bpftool
• Karliss 4y ago
  Isn't BPF execution constraints intentionally very tight, 4096 instruction, 512 bytes of stack, limited control flow? I don't think it's currently usable to implement general purpose drivers. Only reason it could work for HID drivers is because a lot of them are doing nothing more than very simple byte substitution either in device descriptor or the actual data reports. So I am not too worried about closed source driver.
  • mdaverde 4y ago
    eBPF has changed several of these constraints [0] - Verifier can explore up to 1million insns now instead of 4096 - 512 bytes of stack but with tail chaining you have up to 8k - Bounded loops have been added. Unbounded loops are prevented by design to not stall the kernel [0] https://docs.cilium.io/en/v1.12/bpf/ https://docs.cilium.io/en/v1.12/bpf/