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:47 PM, Alexei Starovoitov wrote:
> On Fri, Mar 27, 2026 at 2:08 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> 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.
> 
> I meant that BTF_ID_NAMED(special_kfunc_list
> would somehow remember that it belongs to BTF_ID_LIST_NAMED
> that started this "scrope" few lines above an actual BTF_ID(..)
> ?
> 
> or for BTF_ID(func, bpf_lsm_bpf_prog_free)
> we consider 'func' to be that 'scope' ?
> 
> we don't have uniqueness across files:
> BTF_SET_START(untrusted_lsm_hooks)
> BTF_ID(func, bpf_lsm_bpf_map_free)
> BTF_ID(func, bpf_lsm_bpf_prog_free)
> ..
> 
> BTF_SET_START(sleepable_lsm_hooks)
> ...
> BTF_ID(func, bpf_lsm_bpf_map_free)
> ...
> BTF_ID(func, bpf_lsm_bpf_prog_free)
> 
> but does it matter?
> This new BTF_ID() will define multiple extern u32 with the same name.
> Make them weak since they point to the same id ?

Let me play with this, maybe I (or AI) can come up with something
like you're describing.

I'll aim to submit a patch next week.