Re: [PATCH dwarves] pahole: Inject kfunc decl tags into BTF

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. 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.

Alan

> jirka




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux