On 28/09/2026 19:04, Wang, Jay wrote: > Alan and Alexei, I’ll address both of your comments in V4 and provide more detailed responses later as well. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ Sounds good. To expand on what I had in mind, as I've tried putting together a generic approach that will work both for your use case - BTF vmlinux delivered as a module - and mine - inline vmlinux BTF delivered as a module. They'd need to be separate modules as some folks might want vmlinux BTF as a module but not want inline BTF. The idea is close to what you had; we have a .BTF.link / .BTF.inline.link ELF section which consists of: #define BTF_LINK_SHA256_LEN 32 /* * A .BTF.link or .BTF.inline.link section identifies the module which * carries a vmlinux BTF section. The module name is NUL terminated and the * field is padded to __MODULE_NAME_LEN. */ struct btf_link { char module_name[__MODULE_NAME_LEN]; u8 sha256[BTF_LINK_SHA256_LEN]; u32 btf_size; } __packed; These sections .BTF.link / .BTF.inline.link live in vmlinux and tell it - the module that delivers the payload - the SHA; and - the size again similar to what you had. The link section is populated at the same time resolve_btfids populates the .BTF_ids section; we add support to resolve_btfids for a --btf_link option of the form --btf_link
:: So in your case it will be --btf_link .BTF:btf_vmlinux:vmlinux.BTF and in mine --btf_link .BTF.inline:btf_vmlinux_inline:vmlinux.BTF.inline The attached patch adds resolve_btfids support for this to give an idea of the approach, and at the final vmlinux linking where we patch BTF ids, we would add the above options. resolve_btfids is written to support multiple --btf_link options, so whichever work lands first could add the support that the other series uses. Hope this helps, Alan