On Fri, Dec 22, 2023 at 04:24:35PM +0000, Alan Maguire wrote: > On 22/12/2023 12:46, Jiri Olsa wrote: > > On Fri, Dec 22, 2023 at 09:55:09AM +0000, Alan Maguire wrote: > >> On 21/12/2023 18:07, Alexei Starovoitov wrote: > >>> On Thu, Dec 21, 2023 at 9:43 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > >>>> > >>>> On 21/12/2023 17:05, Alexei Starovoitov wrote: > >>>>> On Thu, Dec 21, 2023 at 12:35 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > >>>>>> you need to pick up only 'BTF_ID(func, ...)' IDs that belongs to SET8 lists, > >>>>>> which are bounded by __BTF_ID__set8__<name> symbols, which also provide size > >>>>> > >>>>> +1 > >>>>> > >>>>>>> > >>>>>>> Maybe we need a codemod from: > >>>>>>> > >>>>>>> BTF_ID(func, ... > >>>>>>> > >>>>>>> to: > >>>>>>> > >>>>>>> BTF_ID(kfunc, ... > >>>>>> > >>>>>> I think it's better to keep just 'func' and not to do anything special for > >>>>>> kfuncs in resolve_btfids logic to keep it simple > >>>>>> > >>>>>> also it's going to be already in pahole so if we want to make a fix in future > >>>>>> you need to change pahole, resolve_btfids and possibly also kernel > >>>>> > >>>>> I still don't understand why you guys want to add it to vmlinux BTF. > >>>>> The kernel has no use in this additional data. > >>>>> It already knows about all kfuncs. > >>>>> This extra memory is a waste of space from kernel pov. > >>>>> Unless I am missing something. > >>>>> > >>>>> imo this logic belongs in bpftool only. > >>>>> It can dump vmlinux BTF and emit __ksym protos into vmlinux.h > >>>>> > >>>> > >>>> If the goal is to have bpftool detect all kfuncs, would having a BPF > >>>> kfunc iterator that bpftool could use to iterate over registered kfuncs > >>>> work perhaps? > >>> > >>> The kernel code ? Why ? > >>> bpftool can do the same thing as this patch. Iterate over set8 in vmlinux elf. > >> > >> Most distros don't have the vmlinux binary easily available; it needs to > >> be either downloaded as part of debuginfo packages or uncompressed from > >> vmlinuz. > > > > would reading the /proc/kcore be an option? I'm under impression it's > > default for distros but I might be wrong > > > > Good idea, I think it would be an option alright. Yeah, /proc/kcore would work, but only for vmlinux. I mentioned in the other thread about how it probably wouldn't work for kfuncs defined in modules. > 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. I also mentioned in the other thread the link between BTF id sets and available kfuncs is not super obvious. It might be ok for now. But I'll defer to people more familiar with it. BPF iterator would probably work, but it feels a bit complex for what is mostly static data. And for data that doesn't really need to be introspected (just BTF IDs). So I'm not sure it's the most ergonomic approach for userspace to consume. Maybe some kind fo sysfs file would be better? Could be as simple as a space separated list of BTF IDs that reference kfuncs. Thanks, Daniel
