Re: [PATCH bpf-next v3 1/2] bpf: Support struct btf_struct_meta via KF_IMPLICIT_ARGS

[Ihor Solodrai <ihor.solodrai@linux.dev>]

On 3/27/26 2:00 PM, Alexei Starovoitov wrote:
> On Fri, Mar 27, 2026 at 1:55 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> On 3/27/26 1:48 PM, Alexei Starovoitov wrote:
>>> On Thu, Mar 26, 2026 at 12:13 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>>>
>>>> [...]
>>>>
>>>> The above works, and the question now is if we like this mechanism
>>>> more than current setup with explicit enums.
>>>
>>> Got it. Thanks for the explanation.
>>> Your approach does sound a lot better than explicit enums.
>>> Make a proper patch out of it.
>>>
>>> If we do this can we remove <counter><line> approach everywhere
>>> while at it and only use named ?
>>
>> This crossed my mind too. I'll try to *replace* the suffixes and if
>> it works fine submit that.
>>
>> One inconvenience is that with named suffixes BTF_ID() macro will
>> have to accept an additional arg (the list name), but I think
>> that's ok. We already have to pass struct/func everywhere too.
> 
> and that name has to be unique.. I think it's fine.
> I'd do such change, and reuse all of BTF_ID macros.
> So that only BTF_SET_START line will differ.
> 
> The overall diff stat shouldn't be big ?

Depends on whether we are refactoring BTF_ID, or just adding new
BTF_ID_NAMED set of macros.

Refactoring would touch every single BTF_ID usage, and that's
pretty invasive:

$ grep -r 'BTF_ID(' --include="*.[ch]" | wc -l
307

$ grep -rl 'BTF_ID(' --include="*.[ch]" 
fs/bpf_fs_kfuncs.c
include/linux/btf_ids.h
kernel/bpf/bpf_lsm.c
kernel/bpf/bpf_struct_ops.c
kernel/bpf/btf.c
kernel/bpf/cpumask.c
kernel/bpf/crypto.c
kernel/bpf/helpers.c
kernel/bpf/verifier.c
kernel/trace/bpf_trace.c
net/bpf/test_run.c
net/core/filter.c
net/core/xdp.c
net/netfilter/nf_conntrack_bpf.c
net/sched/bpf_qdisc.c
tools/include/linux/btf_ids.h
tools/testing/selftests/bpf/prog_tests/resolve_btfids.c
tools/testing/selftests/bpf/test_kmods/bpf_testmod.c