On Sun, 20 Aug 2006 09:54:14 +0100, Dieter wrote: > > > My understanding is that the real reason the penguins keep changing the > > > interface is to discourage binary-only drivers. It isn't working. > > > If the penguins don't want binary drivers, than ban them. Constantly > > > churning the interface just creates problems. > > > > AFAICU, the reason behind no specified ABI (outside the kernel) is that > > the kernel coders wishes to have the freedom to change them without being > > tied to backwards-compatibility problems... I.e. they are not doing this > > to "discourage" binary-only modules/drivers... > > That's the stated reason, which may or may not be the real reason.
The problem is not a secret that they're not telling you. The problem is that there is no general agreement among Linux kernel hackers on this question. Some leading developers consider proprietary kernel modules illegal derived works, some are even threatening to legally inconvenience certain hardware vendors. Others don't care. Binary-only modules are certainly _not_ considered first class citizens. For quite some time now, some symbols have not been available for use by binary-only modules. And internal APIs are changed (almost) without any regards for binary-only drivers (there have been exceptions). > If it is the real reason, it doesn't speak well of their ability to > design an interface if they are constantly having to change it in > ways that break backwards-compatibility. You are misunderstanding how the reasoning works. They don't _have_ to. And they certainly don't increase their own workload just to spite the maintainers of binary-only drivers. But since they care little or nothing about binary-only modules, the cost of changing internal interfaces is limited to changing the drivers that are in the tree. I've done it myself, it's no big deal and pretty useful sometimes. No compatibility (that we care about) is broken, since all in-tree code is fixed. It's one possible approach, and there are pros and cons. Roger _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
