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 257196
To read all comments associated with this story, please click here.
RE[7]: I wonder...
by kaiwai on Sun 22nd Jul 2007 10:57 UTC in reply to "RE[6]: I wonder..."
kaiwai
Member since:
2005-07-06

Now, if the Iraqi invasion was prototyped first... :-)


Iraq is more like a situation where the leader surrounds himself with ideologues and isolates himself from any contrary views.

Basically, it was a battle on two fronts that dooms to failure any country who has ever tried it (something Bismark repeated over and over again regarding the downful of those who tried) and worse still, an attempt to do the invasion on the cheap - Champagne lifestyle on a Coca Cola budget.

Seriously, after getting stuck in crap code, I've had enough of the "code first and ask questions later" approach. I never had a formal education in real program design, so I don't know all the fancy theories, but it can't be that hard to see that leaving out planning is going to backfire in major and unexpected ways later, causing countless lost hours of creating workarounds to rushed or badly planned code.


Believe me, just look at the number of opensource projects that have needed large rewrites because of inadequate code separation, inadequate infrastructure in the code design to allow for future expansion without a complete break in compatibility, code thats so ugly it could crack a mirror.

The problem is that there are too many programmers who want to jump right into the code before doing the boring work - planning. The programming is the easy part, the difficult part is the planning, thats why there are so many programmers who avoid doing that leg work.

Creating prototypes, whenever you can, is the best kind of feedback, I think, but it probably also depends on the context in which you are designing your stuff and how experienced you are in the matter.
I use an iterative approach, and if I have to do 10 prototypes before moving on and putting it into live production code, I'll do that, because I'm pretty sure that the 10th prototype will pay off later.


Creating prototypes are good for 'first time' internal development within an organisation - generally speaking to get feedback on the GUI. But once a trend has been established, 'best GUI practices' in regards to internal programme development should be written up and required reading for all programmers who work at the company before starting on any project.

Again, the problem is, people don't want to write documentation - they want to just fire code at a problem and hope that it works - inadequate documentation, poor code quality and lack of following internally written 'best practices' ends up to code which is unmaintainable for the longterm.

Reply Parent Score: 5