On Fri, Jan 21, 2022 at 07:39:53PM +0000, Usama Arif wrote: > This patchset is a working prototype that adds support for calling helper > functions in eBPF applications that have been defined in a kernel module. > > It would require further work including code refractoring (not included in > the patchset) to rename functions, data structures and variables that are > used for kfunc as well to be appropriately renamed for module helper usage. > If the idea of module helper functions and the approach used in this patchset > is acceptable to the bpf community, I can send a follow up patchset with the > code refractoring included to make it ready for review. > > Module helpers are useful as: > - They support more argument and return types when compared to module > kfunc. What exactly is missing? > - This adds a way to have helper functions that would be too specialized > for a specific usecase to merge upstream, but are functions that can have > a constant API and can be maintained in-kernel modules. Could you give an example of something that would be "too specialized" that it's worth maintaining in a module, but not worth maintaining in the kernel? Also see: https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html#q-new-functionality-via-kernel-modules Why do you think we made that rule years ago?
