Conversation
Lorenzo Stoakes
ljs
Edited 8 months ago
As interesting a technology as bpf is, I really do worry that some aspects of it are just a way of working around the GPL and exfiltrating things from the kernel.
It is potentially (very!) useful to be able to hook into things, but when you get to the point of actually changing kernel behaviour will it not be tempting for companies to implement 'secret sauce' they don't have to contribute back?
EDIT: It is highly likely these programs would be licensed under GPL so that concern is dropped. However stability and maintainer burden concerns are valid.
It is potentially (very!) useful to be able to hook into things, but when you get to the point of actually changing kernel behaviour will it not be tempting for companies to implement 'secret sauce' they don't have to contribute back?
EDIT: It is highly likely these programs would be licensed under GPL so that concern is dropped. However stability and maintainer burden concerns are valid.
1
0
0
Not sure if the license is the biggest problem, as quite a few bits exported to BPF progs are GPL exported as well: https://docs.kernel.org/bpf/bpf_licensing.html#using-bpf-programs-in-the-linux-kernel
I worry more about "we can work around a oddity or missing feature in the Linux kernel's C code using a BPF program, so why should we invest time and money to improve the C code?"
2
0
2
Thorsten Leemhuis (acct. 1/4)
kernellogger@fosstodon.orgsee also this recent post from Mel regarding the BPF extensible scheduler class: https://lore.kernel.org/all/20230926092020.3alsvg6vwnc4g3td@suse.de/
1
0
2
Lorenzo Stoakes
ljs
@kernellogger OK striikes me that any sched changes will be covered:-
...
[in reference to code needing to be GPL licensed]
The same restriction applies to BPF programs that call kernel functions directly via unstable interface also known as "kfunc".
...
Which is a relief.
...
[in reference to code needing to be GPL licensed]
The same restriction applies to BPF programs that call kernel functions directly via unstable interface also known as "kfunc".
...
Which is a relief.
0
0
2
Lorenzo Stoakes
ljs
@kernellogger yeah, Mel is a god-king and that is very valid.
I have _opinions_ about tunables as well which are like a way way way less risky way of doing such things but still problematic in many cases
I have _opinions_ about tunables as well which are like a way way way less risky way of doing such things but still problematic in many cases
0
0
2