On Wed, Jan 04, 2023 at 10:43:37AM -0800, Andrii Nakryiko wrote: > > extern bool bpf_dynptr_is_null(const struct bpf_dynptr *p) __ksym; > > > > will likely work with both gcc and clang. > > And if it doesn't we can fix it. > > > > While when gcc folks saw helpers: > > > > static bool (*bpf_dynptr_is_null)(const struct bpf_dynptr *p) = (void *) 777; > > > > they realized that it is a hack that abuses compiler optimizations. > > They even invented attr(kernel_helper) to workaround this issue. > > After a bunch of arguing gcc added support for this hack without attr, > > but it's going to be around forever... in gcc, in clang and in kernel. > > It's something that we could have fixed if it wasn't for uapi. > > Just one more example of unfixable mistake that causing issues > > to multiple projects. > > That's the core issue of kernel uapi rules: inability to fix mistakes. > > This is BPF ISA defining `call #N;` to call helper with ID N, which > you agree that it (ISA) has to be stable, documented and standardized, > right? > > Everything else is just how we expose those constants into C code and > how libbpf deals with them. Libbpf could support new attribute or even > extern-based convention, if necessary. > > But it wasn't necessary for years and only was brought up during GCC's > attempt to invent a new convention here. And they successfully dealt > with this challenge. 'dealt with this challenge'? You mean didn't, right? gcc doesn't guarantee that '= (void *) 777;' will work even with optimization on. In clang we cannot guarantee that either. Nothing requires a compiler to do constant propagation. > > Yes, we won't change existing helpers, but we can add new ones if we > need to extend them. That's how APIs work. Yes, they need careful > considerations when designing and implementing new APIs. Yes, mistakes > do happen, that's just fact of life and par for the course of software > development. Yes, we have to live with those mistakes. Nothing changed > about that. > > But somehow libraries and kernel still produce stable APIs and > maintain them because they clearly provide benefits to end users. Did you 'live with mistakes done in libbpf 0.x' ? No. You've introduced libbpf 1.0 with incompatible api and some users suffereed. > We'll get the same amount of flame when we try to change kfunc that's > widely adopted. Of course. That's why we need to define a stability and deperecation plan for them.
