On Mon, Dec 7, 2020 at 8:15 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > > > On Mon, Dec 7, 2020 at 3:03 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > >> > >> Wait, what? This is a regression that *breaks people's programs* on > >> compiler versions that are still very much in the wild! I mean, fine if > >> you don't want to support new features on such files, but then surely we > >> can at least revert back to the old behaviour? > > > > Those folks that care about compiling with old llvm would have to stick > > to whatever loader they have instead of using libbpf. > > It's not a backward compatibility breakage. > > What? It's a change in libbpf that breaks loading of existing BPF object > files that were working (with libbpf) before. If that's not a backward > compatibility break then that term has lost all meaning. The user space library is not a kernel. The library will change its interface. It will remove functions, features, etc. That's what .map is for.
