| |||||||||||||
Avoiding the OS abstraction trapAvoiding the OS abstraction trapPosted Aug 15, 2011 9:08 UTC (Mon) by linusw (subscriber, #40300)In reply to: Avoiding the OS abstraction trap by thedevil Parent article: Avoiding the OS abstraction trap
I always nurtured the idea that we grossly overestimate the pain of writing code, especially concerning device drivers. Coding is easy, know-how is hard.
So writing three different device drivers tailored for three differen OS:es isn't necessarily that bad, as long as you have people who are actually comfortable with diving around all three codebases and making sure the know-how about the hardware is shared between all three codebases.
The key assumption I do is that if a developer is to focus on one technical aspect at a time across several codebase rather than one specific codebase across several technical aspects at a time, the outcome may be better.
This may be true to varying extent in different contexts, it's just my intuitive feeling.
(Log in to post comments)
Avoiding the OS abstraction trap Posted Aug 15, 2011 17:14 UTC (Mon) by misiu_mp (guest, #41936) [Link]
"Coding is easy, know-how is hard."
So true. To write a good driver you need to know both the hardware's secrets and the kernel's secrets. It is basically impossible to have a driver that does not need kernel secrets - which an abstracted driver tries to do (exception being the graphics drivers based on the opengl specs).
There is much more people with kernel knowledge than a with particular hardware knowledge. A well documented driver written in a language that is easy to understand to kernel hackers will widen the potential circle of hardware knowledgeable people. Once the know-how is out there or easy to reach, the writing is a formality.
|
|||||||||||||