On Fri, Nov 4, 2022 at 9:12 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > On 04/11/2022 15:59, Alexei Starovoitov wrote: > > On Fri, Nov 4, 2022 at 7:35 AM KP Singh <kpsingh@xxxxxxxxxx> wrote: > >> > >> On Fri, Nov 4, 2022 at 6:16 AM Vitaly Chikunov <vt@xxxxxxxxxxxx> wrote: > >>> > >>> Hi, > >>> > >>> We need to reduce kernel size for aarch64, because it does not fit into > >>> U-Boot loader on Raspberry Pi (due to it having fdt_addr_r=0x02600000) > >>> and one of big ELF sections in vmlinuz is .BTF taking around 5MB. > >>> Compression does not help because on aarch64 kernels are > >>> uncompressed[1]. > >>> > >>> Is it theoretically possible to make sysfs_btf a module? > >> > >> I think so, it may need some refactoring and changes > >> but, yeah, in theory, the module could ship with the > >> kernel's BTF information which can then be initialized by the module. > >> > >> Curious to see what others think as well. > > > > Yeah. That request came up a few times. > > Whoever has cycles to work on it... please go ahead :) > > > > We've experimented with this a bit for the global variable patch > series, where global variable BTF is a tristate config > parameter, and if set to 'm' the BTF for variables ends up in > vmlinux_btf_extra.ko instead (patch series forthcoming; it was > stuck behind the dedup issues which took a while to uncover). > One approach would be to extend that scheme such that > CONFIG_DEBUG_INFO_BTF=m I guess? makes sense. > The only thing that might require change is the name; vmlinux_btf > might be a more appropriate module name than vmlinux_btf_extra > perhaps? Thanks! yeah. vmlinux_btf as a module name should work. libbpf can be taught to look at /sys/kernel/btf/vmlinux and vmlinux_btf.
