* Casper Hornstrup chorns@users.sourceforge.net [2004-02-15 17:16:50 +0100]:
Same reason many companies don't bother to support Linux. Linux kernel-mode APIs change very often and Linux APIs are usually not backwards compatible.
Well, that's one reason where it gets its performance and flexibility from.
BTW: the APIs for things which are interesting for hardware vendors dont change very much (normally in one major release, the things stay the same - and they dont change in less than a year) Binary interfaces may change several times, but it just takes a recompile to make it work. At least you have to ship two builds, one for smp + no-smp. Also different builds for several architectures are required.
So you want to set up a buildfarm for those different targets. Once we have one, it doesnt really matter if we have distinctions between kernel versions.
And if you really _need_ binary compatibility, its possible to plug in an ABI-adaptor, which allows running third-party binary modules. This of course, takes away all these optimizations for those modules, but they're working.
So it doesnt need to develop a new kernel just to have a consitent driver ABI.
<snip>
So, if you want to support two Linux distributions which are compiled with different compilers, then you need to distribute two binaries of your driver. If you want to support SMP configuration (in addition to UP configuration), you need to distribute two additional binaries.
What's the problem ? Some hardware vendors are already doing it.
If you really, really want one binary module (i.e. you feel you cannot publish sourcecode due some contracts) you can write a very small wrapper which loads the real binary driver. This wrapper will be opensource and built against the current kernel.
Have a look at nvidia's binary drivers. They went this way.
cu