On Mon, Dec 7, 2020 at 2:18 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > > > On Mon, Dec 7, 2020 at 8:51 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > >> > >> Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > >> > >> > 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. > >> > >> Right, OK, so how do I use .map to get the old behaviour here? That's > >> all I'm asking for, really... > > > > Fix old llvm. The users would have to upgrade either from llvm 7.x to > > 7.x+1 or to llvm 10+. > > Right, so by "we keep a stable interface" you mean "we expect you to > upgrade your entire toolchain every time you update the library". Gotcha! No. It means that libbpf is not going to have a workaround for every possible llvm bug that was fixed over the years. libbpf already does a ton of fixups for things that users can actually hit.