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
