Re: Possibly offtopic : Binary only driver
On Sun, 21 Nov 2004 15:57:45 +0100, Arjan van de Ven wrote:
actually we do. We keep our *designed* interface to userspace rather
constant and stable.
Yes, you guys do a good job of that.
That is not the same as the *internal* design of the kernel. That we
keep changing and improving all the time. And that's fine, that is why
we have (almost) all drivers in the main tarbal/rpm and.. well.. the
Well, almost all except:
- nvidia binary driver, required for 3D on a large number of peoples
systems
- ndiswrapper, required for compatibility with a large number of wireless
cards
- all the drivers that aren't in tree because they don't meet the coding
standards etc, of which there are a bunch around on sourceforge
- probably more examples I'm not aware of.
rest is required to be GPL anyway in principle so can be adjusted.
I thought binary modules were OK, hence the whole GPL vs non-GPL symbol
versioning system?
At least that's the intention. Some people think they can get
away with
not being GPL while still using and depending on deep kernel internals;
well... to be honest the pain is on them though.
Actually the pain is on the users. You just don't see it.
eg, users don't use kernel upgrades because X refuses to load because the
nvidia kernel module was rejected. Users learn that if they choose the old
option on the grub bootup screen things work. If they choose the new one,
things break. Solution? Always use the old kernel. This sort of logic is
very common amongst less than technical users.
As for your comparison to X, glibc, gtk etc, those EXTERNAL
interfaces
remain stable, just like the kernel external interface is.
The X server has provided a stable driver interface for a very long time
now. GTK provides a stable interface for theming engines, glibc for DNS
resolver plugins and so on. Clearly the kernel *does* provide an interface
to modules, which developers have to use to get support for their hardware
on Linux, the fact that it's a hopelessly unstable interface just causes
pain for all concerned. It doesn't magically reverse policy decisions
taken for business/legal reasons.
A better system would be to actually use the concept of stable/unstable
trees, eg so a stable kernel module ABI subset is maintained throughout
the 2.6 series then broken again at 2.8. The kernel module interfaces can
continue to evolve, but users still get some stability.
As it is the concept of stable/unstable trees is pretty much unofficial
and not really formally specified anywhere.
But those
projects do change the internal interfaces a lot.. just they don't allow
anyone to see it, unlike the kernel where modules do get to see it.
As already pointed out, these projects actually make it clear which
interfaces are internal and which aren't. Whether you like it or not,
parts of the module interface aren't internal, they are being used by
external developers sometimes because they have no choice.
thanks -mike