On Thu, 2006-05-18 at 17:16 +0200, Carl-Daniel Hailfinger wrote: > 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
It does help. Makes one wonder how a company can supply one driver for M$ XP that never needs updating for the life of the product. Perhaps that is one of the reasons for so many security holes in the product. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
