On 25/08/2022 19:53, Andrii Nakryiko wrote:
> On Wed, Aug 24, 2022 at 11:11 AM Eyal Birger <eyal.birger@xxxxxxxxx> wrote:
>>
>> The helper value is ABI as defined by enum bpf_func_id.
>> As bpf_helper_defs.h is used for the userpace part, it must be consistent
>> with this enum.
>
> I think the way we implicitly define the value of those BPF_FUNC_
> enums is also suboptimal. It makes it much harder to cherry-pick and
> backport only few latest helpers onto old kernels (there was a case
> backporting one of the pretty trivial timestamp fetching helpers
> without backporting other stuff). It's also quite hard to correlate
> llvm-objdump output with just `call 123;` instruction into which
> helper it is.
>
> If each FN(xxx) definition in __BPF_FUNC_MAPPER was taking explicit
> integer number, I think it would be a big win and make things better
> all around.
>
> Is there any opposition to doing that?
No objection from my side, for what it's worth.
As a side note, and in case it's useful to anyone, I've played a bit in
the past with clang from Python to parse the UAPI header:
#!/usr/bin/env python3
from clang.cindex import Index, CursorKind
index = Index.create()
translation_unit = index.parse(None, ['include/uapi/linux/bpf.h'])
if not translation_unit:
raise Exception("unable to load input")
elements = []
for node in translation_unit.cursor.get_children():
if node.type.spelling == "enum bpf_func_id":
for val in node.get_children():
elements.append(val.spelling)
print(elements)
print(elements.index('BPF_FUNC_trace_printk'))
$ python3 script.py
['BPF_FUNC_unspec', 'BPF_FUNC_map_lookup_elem', [...],
'BPF_FUNC_ktime_get_tai_ns', '__BPF_FUNC_MAX_ID']
6
I'd love to use something like this to make scripts/bpf_doc.py more
robust, but I've refrained because of the dependency on the clang library.
Quentin
