Re: [PATCH bpf-next v3 03/13] docs, libbpf: Document complete BTF annotation strings

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

On 10/30/26 5:16 PM, bot+bpf-ci@kernel.org wrote:
>> docs, libbpf: Document complete BTF annotation strings
> 
> TL;DR: The BTF docs drop the old bare attribute-list form for kflagged tags
> without noting it. Older kernel BTF uses it, so consumers following the new
> text may print "address_space(1)" uncompilably. Should btf.rst mention it?
> 
>> diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
>> index 29de1222c3e7..98c1f0440f8b 100644
>> --- a/Documentation/bpf/btf.rst
>> +++ b/Documentation/bpf/btf.rst
> 
> [ ... ]
> 
>> @@ -539,8 +540,9 @@ normal type tag, and the ``name_off`` encodes btf_type_tag attribute
>>  string.
>>
>>  If ``info.kind_flag`` is 1, then the type tag represents an arbitrary
>> -__attribute__, and the ``name_off`` encodes a string representing the
>> -attribute-list of the attribute specifier.
>> +annotation. As with decl tags, ``name_off`` encodes the complete annotation
>> +string, which ``btf_dump`` prints unchanged. An attribute specifier must
>> +include its wrapper, for example ``__attribute__((address_space(1)))``.
>>
>>  2.2.19 BTF_KIND_ENUM64
>>  ~~~~~~~~~~~~~~~~~~~~~~
> 
> The old text, which described the string as the attribute-list (for example
> aligned(4)), is removed without any note that BTF in that older form exists.
> Should the format reference say something about it?

I don't think so, because the only significant consumer of the old
format is bpftool, and it handles it correctly.

> 
> [...]