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."
Thread beginning with comment 257196
To view parent comment, click here.
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

RE[8]: I wonder...
by psychicist on Sun 22nd Jul 2007 14:26 in reply to "RE[7]: I wonder..."
psychicist Member since:
2007-01-27

I have been doing some programming with OpenOffice.org over the last one and a half years. As the UNO API has a very broad perspective I started out with Basic to get a little grasp of what was possible without getting overwhelmed with its intricacies.

A friend of mine who needed some automation for time-consuming repetitive tasks asked for my help and I wrote a routine in Basic that could solve some of these. His requirements changed three times and as a result the code looks pretty ugly and looks unmaintainable to me and I consider it a dead-end even though I always start out designing before I implement something.

I have since rewritten the code in Java and to me it looks a lot cleaner and more maintainable because this time around I knew what the code was supposed to do. The moral of this is that as butters told you, you can't always start out with a design and implement it because design considerations can also change.

I have also read Sun's OpenSolaris design manifesto and I admire and applaud them for their approach to design and implementation, but not everyone is a world-class engineer so instead of getting the design and implementation right the first time they need several tries more.

Reply Parent Score: 4

RE[9]: I wonder...
by kaiwai on Mon 23rd Jul 2007 00:59 in reply to "RE[8]: I wonder..."
kaiwai Member since:
2005-07-06

I have been doing some programming with OpenOffice.org over the last one and a half years. As the UNO API has a very broad perspective I started out with Basic to get a little grasp of what was possible without getting overwhelmed with its intricacies.

A friend of mine who needed some automation for time-consuming repetitive tasks asked for my help and I wrote a routine in Basic that could solve some of these. His requirements changed three times and as a result the code looks pretty ugly and looks unmaintainable to me and I consider it a dead-end even though I always start out designing before I implement something.

I have since rewritten the code in Java and to me it looks a lot cleaner and more maintainable because this time around I knew what the code was supposed to do. The moral of this is that as butters told you, you can't always start out with a design and implement it because design considerations can also change.


But that can be due to poor communication between the end user and programmer - if the programmer simply does a 'one off' chat with the client then runs off to hide in a crypt to write up the code, its the equivalent of not enough planning.

It is about making the end user/customer understand what involved with with writing the program - the necessity of them needing to understanding that after a certain point in the process, any features they want/need will need to wait for future versions.

Sometimes as a programmer you have to say to the customer "if you want this, it will delay your programme indefinitely" - make them realise that their constant barrage of requests will eventually stop any opportunity of the product actually shipping.

I have also read Sun's OpenSolaris design manifesto and I admire and applaud them for their approach to design and implementation, but not everyone is a world-class engineer so instead of getting the design and implementation right the first time they need several tries more.


If you do enough study before hand, it shouldn't need to result in massive re-writes - yes, it might take days, weeks or months to get it all working on paper before implementing it. But like I said, once all that has been done, the easy part is firing the code onto a IDE and voila - all done.

Edited 2007-07-23 01:04

Reply Parent Score: 2