On 8 Aug 2025, Alexei Starovoitov stated: > On Thu, Aug 7, 2025 at 7:36 PM Arnaldo Carvalho de Melo > <arnaldo.melo@xxxxxxxxx> 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.
