On Wed, Apr 22, 2026 at 3:44 AM Alan Maguire <[email protected]> wrote: > > On 25/03/2026 01:18, Sasha Levin wrote: > > Move BTF type format parsing and inspection code out of the BPF > > subsystem into its own kernel/bf/ directory, separating core BTF > > functionality from BPF-specific extensions. > > > > CONFIG_DEBUG_INFO_BTF currently depends on CONFIG_BPF_SYSCALL, which > > prevents embedded, automotive, and safety-critical environments from > > using BTF. These platforms often disable BPF for security and size > > reasons but would benefit from BTF type information for crash > > diagnostics and debugging. > > > > I had a go at a refactor in this area too, and it's pretty tricky. How about > we start with a smaller goal; making /sys/kernel/btf available to userspace > on systems without CONFIG_BPF_SYSCALL? This would just involve a small > refactor > of the BTF module-related stuff in kernel/bpf/btf.c, moving it to btf_module.c > or similar say. No need to split out BTF parsing APIs from those actively > used in > validating BPF etc, since a non-BPF_SYSCALL system would not need to parse BTF > in the kernel (just make it available in sysfs.
Small refactor is ok, but in general I'm not interested in complicating code for systems without CONFIG_BPF_SYSCALL.
