If you don't mind, what makes more niche hardware drivers work / build better against RHEL?
I suppose RHEL uses basically the same kernel, with patches that don't alter its interface too substantially. So I presume that a driver in source form, or even partly in binary blob form, should build and work approximately equally well with any stock kernel.
Beside the driver developers apparently using RHEL / CentOS (so on them the drivers are known to work), what am I missing?
> I suppose RHEL uses basically the same kernel, with patches that don't alter its interface too substantially. So I presume that a driver in source form, or even partly in binary blob form, should build and work approximately equally well with any stock kernel.
No, I think that's exactly the difference; Linux (in)famously has no stable ABI for drivers, and regularly makes changes that break things if you don't recompile against the updated kernel. Part of the value in RHEL was that they froze significantly more ABI surface, which made it possible to write proprietary drivers that would work across at least minor kernel updates without needing to be changed. That won't work on an upstream kernel because upstream doesn't go out of their way to freeze that ABI surface.
Maintaining any kernel modules that are not in the Linux kernel tree is extremely painful.
Almost every new kernel version breaks the older kernel modules, e.g. device drivers, by moving definitions between kernel headers, by adding or deleting function parameters, or by adding or deleting structure members.
Most of these changes are very poorly documented, so anyone who does not follow daily the kernel development is clueless for instance about which values should be put in the new function parameters or new structure members in order to obtain the same behavior as in the previous kernel version.
The kernel developers who make these breaking changes do not bother to write upgrading instructions for the benefit of those who must maintain an out-of-tree device driver, so those may have to waste a lot of time with reading the kernel sources, to discover what must be done to make the old device drivers compatible with a new kernel.
The kernel devs argue that the goal should be to get in-tree so these changes are taken care of for you by the people driving the ABI changes, and I happen to agree with them in that regard.
Nearly every Android device ever made runs on an outdated kernel that can't be upgraded anymore. From a platform perspective, I think they made the wrong choice when the majority of their install base has turned into abandonware.
It is both drivers and the userland tools that you get in the tarball. This stuff is often developed by people with a focus on hardware. They will build something to work well on their machine but may never have used a different linux distro. The userland tools might assume compile options in libraries will be as they are in redhat. There will be hard coded paths where there shouldn’t be. The source may not be available, it might be static binaries. That kind of stuff.
In my past experience as a sysadmin, some vendors will only release drivers (as binary blobs) for RHEL. EMC PowerPath comes to mind, granted that's kind of a moot point now that the FOSS kernel MPIO drivers are good enough, but I'm sure there's other such examples that exist to this day.
Targeting a RHEL kernel version is quite different than targeting the same official kernel version as they backport a huge number of features, resulting in drivers that may work in RHEL but not upstream, or the reverse
In my experience RHEL has been better at backporting patches and maintaining a relatively stable kernel. This means that third-party software that targeted it is more likely to work over time. Canonical by comparison is absolutely terrible, and seemingly just blindly imports whatever is thrown over the wall from kernel.org even in their so-called "LTS" versions, and now after running an innocuous "apt-get upgrade" command your frobnitz device no longer works and/or you can't rebuild the driver for your frobnitz device due to incompatible kernel changes.
Some vendors also explicitly detail exactly which distro and versions they support ("RHEL or Centos x.y"), so even if you can get things to work on another distro, a vendor can easily deny your support request with the usual BS line: "that configuration is not supported. Switch back to RHEL x.y or SLES and let us know if you can reproduce the issue! La-la-la have a nice day, buh-bye! phone click".
I suppose RHEL uses basically the same kernel, with patches that don't alter its interface too substantially. So I presume that a driver in source form, or even partly in binary blob form, should build and work approximately equally well with any stock kernel.
Beside the driver developers apparently using RHEL / CentOS (so on them the drivers are known to work), what am I missing?