Em Tue, Mar 09, 2021 at 08:14:50PM -0800, Andrii Nakryiko escreveu: > On Tue, Mar 9, 2021 at 1:57 PM Ilya Leoshkevich <iii@xxxxxxxxxxxxx> wrote: > > On Tue, 2021-03-09 at 13:37 -0800, Andrii Nakryiko wrote: > > > On Tue, Mar 9, 2021 at 3:48 AM Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote: > > > > Em Tue, Mar 09, 2021 at 12:59:13AM +0100, Ilya Leoshkevich escreveu: > > > TBH, I think it's not exactly right to call out libbpf version > > > here. It's BTF "version" (if we had such a thing) that determines > > > the set of supported BTF kinds. There could be other libraries > > > that might want to parse BTF. So I don't know what this should be > > > called, but libbpf_compat is probably a wrong name for it. > > BTF version seems to exist: btf_header.version. Should we maybe bump > > this? > That seems excessive. If the kernel doesn't use FLOATs, then no one > would even notice a difference. While if we bump this version, then > everything will automatically become incompatible. > > > If we do want to teach pahole to not emit some parts of BTF, it > > > should > > > probably be a set of BPF features, not some arbitrary library > > > versions. > > I thought about just adding --btf-allow-floats, but if new features > > will be added in the future, the list of options will become unwieldy. > > So I thought it would be good to settle for something that increases > > monotonically. > BTF_KIND_FLOAT is the first extension in a long while. I'd worry about > the proliferation of new options when we actually see some proof of > that being a problem in practice. I tend to agree, Ilya, can you rework the patch in that direction? Something like --encode-btf-kind-float that starts disabled or other suitable name? - Arnaldo
