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 <section>:<module>:<raw-btf-file>
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