On Tue, Apr 9, 2024 at 12:29 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > On Tue, 2024-04-09 at 15:45 -0300, Arnaldo Carvalho de Melo wrote: > > On Tue, Apr 09, 2024 at 06:01:08PM +0300, Eduard Zingerman wrote: > > > 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 > > > > What kind of diff-ing of BTFs from different kernels are you interested > > in? > > > > in pahole's repository we have btfdiff, that will, given a vmlinux with > > both DWARF and BTF use pahole to pretty print all types, expanded, and > > then compare the two outputs, which should produce the same results from > > BTF and DWARF. Ditto for DWARF from a vmlinux compared to a detached BTF > > file. > > > > And also now we have another regression test script that will produce > > the output from 'btftool btf dump' for the BTF generated from DWARF in > > serial mode, and then compare that with the output from 'bpftool btf > > dump' for reproducible encodings done using -j 1 ... > > number-of-processors-on-the-machine. All have to match, all types, all > > BTF ids. > > > > We can as well use something like btfdiff to compare the output from > > 'pahole --expand_types --sort' for two BTFs for two different kernels, > > to see what are the new types and the changes to types in both. > > > > What else do you want to compare? To be able to match we would have to > > somehow have ranges for each DWARF CU so that when encoding and then > > deduplicating we would have space in the ID space for new types to fill > > in while keeping the old types IDs matching the same types in the new > > vmlinux. > > As far as I understand Alexei, he means diffing two vmlinux.h files > generated for different kernel versions. The vmlinux.h is generated by > bpftool using command `bpftool btf dump file <binary-file> format c`. > The output is topologically sorted to satisfy C compiler, but ordering > is not total, so vmlinux.h content may vary from build to build if BTF > type order differs. > > Thus, any kind of stable BTF type ordering would make vmlinux.h stable. > On the other hand, topological ordering used by bpftool > (the algorithm is in the libbpf, actually) might be extended with > additional rules to make the ordering total. Not looking for perfect ordering. People check-in vmlinux.h into their repos. If it's more or less sorted the git diff of updated vmlinux.h will be a bit more human readable. Hopefully.
