Evolving the BPF Type Format
summary
Proposes moving the ~8 MB vmlinux BTF into a separate vmlinux BTF module so embedded kernels avoid image bloat, and adding a standalone BTF renumbering step at module load to remap IDs (prototype patched, work in progress). Adds a small header change (~24 bytes), optional symbol table with function/variable addresses, CRC checks to detect kernel/module mismatches, BTF features/kind-layout to allow forward parsing, and estimates ~1 MB for addresses and ~2 MB for variables when enabled.
AI-written summary · about
chapters (12)
- 0:00Introduction to BTF
- 2:29Moving BTF out of vmlinux
- 5:04Standalone module BTF
- 9:42Usability issues with BTF
- 16:50Optimized function support
- 17:55Disambiguating function names
- 20:43Adding function addresses
- 22:50Supporting global variables
- 23:10BTF kind layout encoding
- 25:34Detecting kernel BTF mismatch
- 26:58Evolving BTF format
- 29:45Future work and summary
related talks
47mBPF: The Status of BTF, producers, consumers.
23mAlways present type information thanks to BPF: BTF
37mThe BTF file format, more than just debugging
08mLightning Talk: BTFGen: one Step Closer to Truly Portable eBPF Programs
44mBoF: Devicetree
45mSupporting BPF in the GNU Toolchain
42mA Deep Dive Into eBPF Program Loader
24mLessons Learned Migrating to Modern Multi-Platform eBPF Programs