Re: [RFC PATCH v7 3/7] tools/resolve_btfids: Add --btf_sort option for BTF name sorting

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

On 11/20/25 1:34 PM, Ihor Solodrai wrote:
> On 11/18/25 7:15 PM, Donglin Peng wrote:
>> From: Donglin Peng <pengdonglin@xiaomi.com>
>>
>> This patch introduces a new --btf_sort option that leverages libbpf's
>> btf__permute interface to reorganize BTF layout. The implementation
>> sorts BTF types by name in ascending order, placing anonymous types at
>> the end to enable efficient binary search lookup.
>>
>> [...]
>>
>> +}
>> +
>> +static int update_btf_section(const char *path, const struct btf *btf,
> 
> Hi Dongling.
> 
> Thanks for working on this, it's a great optimization. Just want to
> give you a heads up that I am preparing a patchset changing
> resolve_btfids behavior.
> 
> In particular, instead of updating the .BTF_ids section (and now with
> your and upcoming changes the .BTF section) *in-place*, resolve_btfids
> will only emit the data for the sections. And then it'll be integrated
> into vmlinux with objcopy and linker. We already do a similar thing
> with .BTF for vmlinux [1].
> 
> For your patchset it means that the parts handling ELF update will be
> unnecessary.
> 
> Also I think the --btf_sort flag is unnecessary. We probably want
> kernel BTF to always be sorted in this way. And if resolve_btfids will
> be handling more btf2btf transformation, we should avoid adding a
> flags for every one of them.

The same applies to --distilled_base.

AFAIU we always want to do it, so there is not need for the
flag. Unless there is a strong use case for generating module BTF
*without* the distilled base that I am not aware of.

Maybe an explicit "--kmodule" flag would be appropriate?..
For resolve_btfids, is it reasonable to assume it's a module if --base
is passed in?

Andrii, Eduard, wdyt?

> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/scripts/link-vmlinux.sh#n110
> 
>