Quote of the week [LWN.net]

Quote of the week

Posted Oct 19, 2006 15:59 UTC (Thu) by quintesse (subscriber, #14569)
Parent article: Quote of the week

Although I understand the reasons behind stable_api_nonsense.txt and can't disagree with it I also understand the other side of all this.

Yes, the best thing would be to have all drivers in the kernel but there are times when that just isn't possible. An example given above was a driver that is built in such a way that it would never be accepted.

The kernel devs might have some very good reasons to disapprove of such a driver in the kernel. But on the other hand there might be very good reasons for some users to do things differently. And the source being freely available makes all this possible of course, but it might be quite difficult at times.

Of course, it's the kernels devs that are spending the time so they are calling the shots.

At times I´ve wondered if it wouldn't be possible for others to make a stable "Device Driver API" that interfaces to the kernel. Drivers would be written for to that API and it would be the responsibility of the API devs to make things work with each kernel. It might not be possible to maintain this API a 100% for very long periods of time, but the fact that for several years I could recompile a driver for a video capture card without having to make any changes to the code seems to suggest that at least it should be possible to make a semi-stable API.

Of course it that were easy to do (or even possible) it would already exist, right?

Ok, I'll continue dreaming now ;-)

(Log in to post comments)

Quote of the week

Posted Oct 20, 2006 14:58 UTC (Fri) by sobdk (guest, #38278) [Link]

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.

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.