Kenneth Schneider wrote:
But it won't even install because the kernel version<> module version. Which was the point to my previous question about why a driver cannot be used with a newer kernel version. The 2.6 kernel is still the 2.6 kernel even if it has .3-5 or .3-55 at the end. If someone writes a driver for the 2.6 kernel it should work no matter what revision level the kernel goes to. But then I am not a programmer only a frustrated user.
Since I am a kernel programmer, please let me explain. The 2.6 kernel series has been going through a remarkably fast evolution since the 2.6.0 release in December 2003. This speed was only possible because the internal kernel interfaces could be changed continuously to match newer requirements. All in-kernel drivers were automatically adapted to the new interfaces on each change, so this was no problem. External drivers, on the other hand, suffer with each interface change. That's why all kernel developers want drivers to be submitted to the standard kernel as soon as possible. Note that so-called stable series (e.g. 2.6.16 -> 2.6.16.12) used in Linux distributions almost never change any interfaces. There are a few reasons why drivers are not submitted to the kernel: * the driver authors do not want it -> their fault, their users suffer. * the driver authors don't know about submitting -> educate them. * the driver crashes or corrupts data from time to time and thus gets rejected -> help the authors with testing so they can fix their bugs and submit the driver. There is one additional reason why a driver is not in the kernel you're working with: * the driver was written or submitted after release of that kernel -> you need a backport of the driver for that kernel, which can be provided by either Novell Developer Services or the device vendor. "But why can't I use a driver for 2.6.16.x also for 2.6.16.y?" Simple. It works perfectly most of the time. There are two reasons why it may fail: 1. A (security) bug is discovered in one driver interface and it has to be changed to fix that bug. Happens rarely. (Solaris had such a bug which could be exploited for years because they didn't want to change the interface.) 2. The driver uses tricks which depend on bugs and peculiarities of a certain specific kernel or on the meaning of special flags which are declared not-for-drivers. Happens often, especially with vmware/nvidia/ati drivers. It is never a good idea to depend on things you're not suposed/allowed to use. Hope this answers your question. Regards, Carl-Daniel -- http://www.hailfinger.org/