On Wed, 2025-07-16 at 16:15 +0100, Nick Alcock wrote: [...] > - So... a third option, which is probably the most BTFish because it's > something BTF already does, in a sense: put everything in one section, > call it .BTF or .BTFA or whatever, and make that section an archive of > named BTF members, and then stuff however many BTF outputs the > deduplication generates (or none, if we're just stuffing inputs into > outputs without dedupping) into archive members. > > So, here's a possibility which seems to provide the latter option while > still letting existing tools read the first member (likely vmlinux): > > The idea is that we add a *next member link field* in the BTF header, and a > name (a strtab offset). The next member link field is an end-of-header- > relative offset just like most of the other header fields, which chains BTF > members together in a linked list: > > parent BTF > | > v > children BTF -> BTF -> BTF -> ... -> BTF > > The parent is always first in the list. Hi Nick, You are talking about BTF section embedded in a final vmlinux binary, right? Could you please elaborate a bit on why do you need multiple members within this section (in the context of your third option)? I re-read the email but don't get it :( [...]
