Re: [RFC 0/4] BTF archive with unmodified pahole+toolchain

[Nick Alcock <nick.alcock@oracle.com>]

On 8 Aug 2025, Alexei Starovoitov stated:

> On Thu, Aug 7, 2025 at 7:36 PM Arnaldo Carvalho de Melo
> <arnaldo.melo@gmail.com> wrote:
>> But the changes in my series are so small that I think they merit consideration even so.
>
> Agree with that as well, but I'm just not easy about "BTF archives" :)
> The name is too ambitious. Concatenated BTF sections is fine,
> but let's not make a big deal out of it.

Just a note about the name -- it's ultimately derived from a thing I
wrote a decade ago to make it easier to package up CTF in kernels
without people losing half of it. It was rather more complex (its
descendant can still be seen at the tip of
https://ourceware.org/git/binutils-gdb.git users/nalcock/road-to-ctfv4
but I expect to remove support for writing that format and move to
something simpler: read support will be kept).

So the name "archive" is already embedded in libctf type names, source
file names, and its public API, and there is code using the term out
there in the wild. It seems like a reasonable term to me -- I mean,
obviously it does, I coined it, but a bunch of concatenated things with
minimal further structure is called an archive when tar does it.

Fundamentally, just as pahole's deduplicator imposes meaning on the BTF
sections in vmlinux and modules, so too libctf's deduplicator imposes
meaning on a concatenated stream of archives ("the first is shared
stuff, the rest is not"), so we do need a way to talk about this entity
in some fashion, for those occasions when it is in use (internally in
the kernel build process, as the content of ELF sections in userspace).

We have to call it *something*, and if you do end up calling it
something other than an archive the existing uses that do call it an
archive aren't going to instantly go away, so now we have to deal with
*two* terms.