On 8 Aug 2025, Arnaldo Carvalho de Melo said: > On August 7, 2025 11:52:51 PM GMT-03:00, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: >>On Thu, Aug 7, 2025 at 7:36 PM Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx> wrote: > >>> On Thu, Aug 7, 2025, 11:09 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > >>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. > > Well, other proposals being discussed would add more metadata to > traverse these archives, I was just tagging along on the jargon being > created :-) We don't actually need *much* more. I think concatenation is less than ideal simply because it's hard to tell when to stop looking for more archive members in a concatenated stream. In the model Jose proposed (more or less the model split BTF is basically already using), the first member is special, being the parent and holding most of the shared types, vmlinux etc. Because it's special, I think we want to be able to identify it even if you, say, take two sections full of concatenated members and concatenate *them*. Just relying on straight concat would have all the tools treating the second vmlinux in that concatenated stream as if it were a module! If there was a link field (or just a "stop here" bit), it could say "there are no more members" reliably, or you could ask tools to hunt through concatenated streams of BTF and tell you which ones in that stream look like they're vmlinuxes (and all the non-vmlinuxes after those are modules). e.g. if you accidentally concatenated vmlinux -> a -> b -> c and vmlinux -> d -> e -> f You would get vmlinux -> a -> b -> c -> vmlinux -> d -> e -> f and it would be nice if the format could at least *tell* that the second vmlinux *was* a vmlinux without relying on awful hacks like "oh it contains basic integer or mm types, it must be vmlinux". We can do that with a link field, or with one single bit saying "stop here", or with a bit saying "this is the parent, start here". I don't mind which. We could also do with a single field (long-existing in CTF, which calls it "cuname") which lets you tell the source of types in different BTF members. The first, the vmlinux/shared one, is easily identifiable, it's first: but all the others need to be told apart somehow. Since each corresponds to a module (in vmlinux) or a compilation unit containing conflicted types (in userspace CTF), giving it *some* sort of optional name field in the header seems necessary. I don't really mind what we call the field: cuname, btf_name, member_name, file_name, anything. > It was just convenient that an unmodified linker was concatenating > everything and that from the existing BTF headers I could use a > preexisting libbpf API, btf__add_btf() merge everything to then use > another preexisting API, btf__dedup() to get to the same end result. Yeah. > I don't see, so far, any other use for a "BTF archive", only as a > happy intermediate step from a one line change to the kernel to get > the linker to have the BTF "Compile Units" put together in the same > order as the DWARF ones for the final merge+dedup. We use them in userspace. (I think I can converge enough, without BTF format changes beyond this one, to completely eliminate .ctf in userspace and just let us use BTF everywhere: but as described in https://lore.kernel.org/dwarves/87bjpkmak2.fsf@xxxxxxxxxxxxx/, the BTF we're using will usually be archives of BTF stuck into a single ELF section, whether we use a link field or concatenation or some weird archive format like I used to, it's going to be multiple BTFs-full in a great many programs). -- NULL && (void)
