On Fri, 4 Oct 2019 18:37:44 +0000, Yonghong Song wrote: > > Having a header which works today, but may not work tomorrow is going > > to be pretty bad user experience :( No matter how many warnings you put > > in the source people will get caught off guard by this :( > > > > If you define the current state as "users can use all features of > > libbpf and nothing should break on libbpf update" (which is in my > > understanding a goal of the project, we bent over backwards trying > > to not break things) then adding this header will in fact make things > > worse. The statement in quotes would no longer be true, no? > > distro can package bpf/btf uapi headers into libbpf package. > Users linking with libbpf.a/libbpf.so can use bpf/btf.h with include > path pointing to libbpf dev package include directory. > Could this work? IMHO that'd be the first thing to try. Andrii, your option (c) also seems to me like a pretty natural fit, although it'd be a little strange to have code depending on the kernel version in tree :S
