On Fri, Dec 22, 2023 at 12:55 PM Daniel Xu <dxu@xxxxxxxxx> wrote: > > > > From a user > > perspective though can we always assume the BTF id sets of kfuncs always > > match the set of available kfuncs? If the goal of this feature is to see > > which kfuncs are available to be used, we'd need some form of active > > participation by the kernel in producing the registered list I think. > > But again, depends what the goal is here. > > The goal is to query for available kfuncs. The list of available kfuncs across all modules and prog types doesn't really help the users to know whether their program will be accepted if they use this kfunc. Today kfuncs are grouped by prog type, but soon it will be more fine grained. We need to allow different set of kfuncs depending on struct_ops attach point and potentially flags at hook attach point. So the list of kfuncs is similar to the list of helpers. Adding kfunc btf_decl_tag to vmlinux BTF and module BTF only helps with generation of vmlinux.h or module.h so that the users don't need to manually write __ksym protos in their programs. Analogous to generation of bpf_helper_defs.h. re: your other email. Extra ~6k for vmlinux BTF is fine. As Dave suggested in the other email let's make sure that dedup removes the duplicated decl_tags or pahole doesn't add another one if btf_decl_tag is already present in __bpf_kfunc macro. pahole will essentially be a workaround for lack of btf_decl_tag in GCC.
