Linux Kernel 2.6.23 To Have Stable Userspace Driver API
Linked by Thom Holwerda on Sun 22nd Jul 2007 00:33 UTC, submitted by liquidat
Linux Linus Torvalds included patches into the mainline tree which implement a stable userspace driver API into the Linux kernel. The stable driver API was already announced a year ago by Greg Kroah-Hartman. Now the last patches were uploaded and the API was included in Linus' tree. The idea of the API is to make life easier for driver developers: "This interface allows the ability to write the majority of a driver in userspace with only a very small shell of a driver in the kernel itself. It uses a char device and sysfs to interact with a userspace process to process interrupts and control memory accesses."
E-mail Print r 0   51 Comment(s) http://osne.ws/e4g
Permalink for comment 257161
To read all comments associated with this story, please click here.
RE[3]: I wonder...
by kaiwai on Sun 22nd Jul 2007 04:50 UTC in reply to "RE[2]: I wonder..."
kaiwai
Member since:
2005-07-06

That kind of is the whole argument of why no stable API is better. By just sticking to one design and not trying anything else or allowing that design to evolve with a stable API, they may be stuck with the original poor design as they are seeing how it is used. If they can redo the design a couple of times, then they can have a better design.


On what basis - you design a stable on the basis of future development; if you design it based solely on todays specifications, of course you're doomed to failure!

Take a look at Sun's own USB stack, for instance - it didn't need to be re-written three times and performs the same if not better than Linux's.

Heck, look at Sun's new network infrastructure for instance, nothing stopped them from pushing some great ideas such as the new network infrastructure - Nemo.

What you're saying to me is that progress without complete breakage is impossible. 25 years of commercial development by way of Windows and various UNIX's says otherwise.

Taking the USB stack as an example, if they tried to keep the original design and make it a stable API, would that be better then the evolutionized and better API that they replaced it with as the USB technology progressed with stuff like USB 2.0 coming out? There are tradeoffs on both sides, and the argument was that for Linux's architecture and development process, they thought that a stable API would hinder the development they wanted, being able to correct any API issues that weren't well thoughtout the first time around without having to worry about any obsolete or deprecated APIs.


And if they had their act together they would have written their code modular enough so that the calls exposed to developers are written in such a way that their call isn't based on some arbitrary condition on based on decisions made further down.

For example; if you expose an API, if you write it correctly, what the heck is being done behind the scenes should not matter a donkey's diddle to the programmer concerned. He throws his request to the API, and lets the appropriate libraries to sort out the low level work then regurgitating it back to the developer again. What happens inside that blackbox is none of the programmers concern.

To say that some how if you change the internal processes, you're forced to change the external outcomes of each call is completely ignoring the basic understanding of programming.

Reply Parent Score: 5