On 17/06/2023 01:39, Alexei Starovoitov wrote: > 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. Sure; I'll roll this into v3 and fix formatting and the typo in btf.h. Thanks!
