|
|
|
|
|
|
by yjftsjthsd-h
1689 days ago
|
|
|
I was thinking specifically in the context of ZFS, which break on minor releases because kernel-internal symbols are not fully stable (unless I've seriously misunderstood https://github.com/openzfs/zfs/issues/11320). And since Stream is a rolling release, users will therefore experience breakage unless they specifically pin their kernel version (or possibly use DKMS). That's ABI breakage, and RH explicitly saying that it doesn't count doesn't stop it breaking stuff that would work in a non-rolling release. |
|
|
If OpenZFS happens to work throughout an entire RHEL minor release and they are using non-kABI symbols (which they are), that is not ABI compatibility: that's _luck_. It is in no-way-shape-or-form any kind of ABI compatibility the way it is defined for RHEL. You can't call RHEL kABI/ABI compatibility something it's not, it has an explicit meaning and definition.
Per the GH issue you provided the project explicitly stated they did their best to reduce as much as possible their reliance on non-kABI symbols. This was accomplished through symbols being added to the RHEL stablelist and OpenZFS reducing the symbols they actually use. If they didn't have to use non-kABI symbols there wouldn't be a problem. I've had NVIDIA kmod's from ELRepo fail _multiple_ times in a single minor release because non-kABI symbols changed, not to mention between minor releases. This is still not an example of RHEL kABI/ABI breakage.