On Fri, Jun 16, 2023 at 06:17:18PM +0100, Alan Maguire wrote: > By separating parsing BTF from using all the information > it provides, we allow BTF to encode new features even if > they cannot be used. This is helpful in particular for > cases where newer tools for BTF generation run on an > older kernel; BTF kinds may be present that the kernel > cannot yet use, but at least it can parse the BTF > provided. Meanwhile userspace tools with newer libbpf > may be able to use the newer information. Overall looks great, but why such narrow formatting? It's much less than 80. > > The intent is to support encoding of kind layouts > optionally so that tools like pahole can add this > information. So for each kind we record > > - kind-related flags > - length of singular element following struct btf_type > - length of each of the btf_vlen() elements following > > In addition we make space in the BTF header for > CRC32s computed over the BTF along with a CRC for > the base BTF; this allows split BTF to identify > a mismatch explicitly. > > The ideas here were discussed at [1], with further > discussion at [2]. > > Future work can take more advantage of these features > such as > > - using base CRC to identify base/module BTF mismatch > explicitly > - using absence of a base BTF CRC as evidence that > BTF is standalone That's fine to have as a follow up, but with BTF_FLAG_CRC_SET the kernel should check the crc. Calling crc32c on modern cpus should be plenty fast. It won't slow down btf verification.
