|
|
Subscribe / Log in / New account

Reconsidering BPF ABI stability

Reconsidering BPF ABI stability

Posted Jan 27, 2023 20:30 UTC (Fri) by iabervon (subscriber, #722)
Parent article: Reconsidering BPF ABI stability

Maybe any stable kfunc should have to use a wrapper (which the compiler could optimize out at build time), such that changing any of the existing kernel functions leads to the wrapper failing to compile (in the same way as other uses of the kernel function) rather than a kernel which compiles but breaks any BPF programs that uses that kfunc.

In order for the kernel to have a function in a stable ABI, it should be necessary to duplicate the current function declaration at some particular time as the stable function declaration, so that changes to the code of some subsystem can't affect what's declared as the stable ABI. You need both "here's what we're promising" and "here's what we're providing" separately, despite the fact that they're the same, so that if they're ever not the same you can detect the issue.

I think it may also be valuable in stabilizing kfuncs if the wrapper could declare that the kfunc it's providing has the name of the kernel function it's wrapping, rather than the name of the wrapper. That would avoid the issue that, for any kfunc that's using an existing kernel function, you're essentially promising to break any existing programs that use it if you make the kfunc stable.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds