Recent Features
| |||||||||||||
Quote of the weekQuote of the weekPosted Oct 20, 2006 14:58 UTC (Fri) by sobdk (guest, #38278)In reply to: Quote of the week by quintesse Parent article: Quote of the week
Of course it is possible, and not all that difficult. It is called an abstraction layer, and this really is a common method for maintaining out of tree drivers. Ever wonder why you have to compile something when you install that evil binary video driver?
The fact is maintaining an out of tree driver isn't all that hard, but manufacturers are lazy. They want to write a driver once, and never touch it again. If this is what they want then write it once, and put it in the kernel. More than likely it will take them 3 kernel releases to get their driver finished in the first place so when they release their hardware they can have an out of tree driver that supports about 3 versions back, and an in tree version.
(Log in to post comments)
Quote of the week Posted Oct 20, 2006 17:29 UTC (Fri) by william.waddington (subscriber, #25316) [Link] _Some_ manufacturers may be lazy. We, on the other hand, are industrious (and trustworthy, loyal, helpful, friendly, courteous, kind...).
No particular problem keeping our drivers current. The problem arises because some users want drivers for the latest kernel, while others are using/will use/want to use older (more stable in their minds) kernels.
If the DKI changes without including compatiblity hooks or "automatic" build options (like the #define above), the user is confronted with a page full of driver versions, and often picks the wrong one.
It's much simpler if the user can just download the latest driver for a given major kernel version and have that work on all kernels up to the latest.
Quote of the week Posted Oct 21, 2006 12:17 UTC (Sat) by anton (guest, #25547) [Link] If the DKI changes without including compatiblity hooks or "automatic" build options (like the #define above), the user is confronted with a page full of driver versions, and often picks the wrong one.The perfctr patch has a nice automatic way of dealing with this problem. Which reminds me that that patch has been submitted for in-kernel inclusion once, and apparently was not accepted (I have not followed the discussion on the reasons, but my impression was that the author did restructure his code to make it more acceptable to the kernel folk.
|
|||||||||||||