On Tue, 2024-04-09 at 07:56 -0700, Alexei Starovoitov wrote: [...] > I would actually go with sorted BTF, since it will probably > make diff-ing of BTFs practical. Will be easier to track changes > from one kernel version to another. vmlinux.h will become > a bit more sorted too and normal diff vmlinux_6_1.h vmlinux_6_2.h > will be possible. > Or am I misunderstanding the sorting concept? You understand the concept correctly, here is a sample: [1] INT '_Bool' size=1 bits_offset=0 nr_bits=8 encoding=BOOL [2] INT '__int128' size=16 bits_offset=0 nr_bits=128 encoding=SIGNED [3] INT '__int128 unsigned' size=16 bits_offset=0 nr_bits=128 encoding=(none) [4] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=(none) [5] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED [6] INT 'long int' size=8 bits_offset=0 nr_bits=64 encoding=SIGNED [7] INT 'long long int' size=8 bits_offset=0 nr_bits=64 encoding=SIGNED ... [15085] STRUCT 'arch_elf_state' size=0 vlen=0 [15086] STRUCT 'arch_vdso_data' size=0 vlen=0 [15087] STRUCT 'bpf_run_ctx' size=0 vlen=0 [15088] STRUCT 'dev_archdata' size=0 vlen=0 [15089] STRUCT 'dyn_arch_ftrace' size=0 vlen=0 [15090] STRUCT 'fscrypt_dummy_policy' size=0 vlen=0 ... (Sort by kind, than by vlen, than by name because sorting by name is a bit costly, then by member properties)
