Avoiding the OS abstraction trap

Posted Aug 14, 2011 11:31 UTC (Sun) by ebirdie (guest, #512)
In reply to: Avoiding the OS abstraction trap by JoeBuck
Parent article: Avoiding the OS abstraction trap

Did you read the article or lacking in understanding the text, or am I? I'll try my shot.

On Linux there is no need to maintain any Kloc for isc driver, if the initial driver development is done the "Linux community way", ie. shared, until the hardware will get revisions, which may need new bits and pieces added in by the vendor development team.

To put it another way with over simplification and has a familiar sound. Write once and forget. ;-)

Avoiding the OS abstraction trap

Posted Aug 14, 2011 16:01 UTC (Sun) by bfields (subscriber, #19510) [Link] (2 responses)

"Write once and forget" overstates the case--the driver will need some ongoing maintenance to keep up with the rest of the kernel, and it's hard for people who don't know the specific driver well to completely take over maintenance. At a bare minimum, you need someone who has access to the hardware and can test new kernels.

We certainly hope contributors can reduce their maintenance load, but if we lead them to expect it to be reduced to zero, then we risk ending up with a lot of bit-rotted drivers.

Avoiding the OS abstraction trap

Posted Aug 15, 2011 16:38 UTC (Mon) by misiu_mp (guest, #41936) [Link] (1 responses)

The point of this rewriting is that the future maintenance will be possible by someone outside the original development team. So although you will probably need a person with the hardware to test it, it could be an ordinary savvy user. That's because the driver is now much simpler and similar to other drivers, instead of being the very specific and complicated cake of layers that it used to be. It's got a better Bus factor .

Avoiding the OS abstraction trap

Posted Aug 16, 2011 6:20 UTC (Tue) by ebirdie (guest, #512) [Link]

"the driver is now much simpler and similar to other drivers, instead of being the very specific and complicated cake of layers"

I love this, because to me it implies that the piece of hardware (ie. a chip and its surrounding implementation) has better chances to shine on its own as hardware and not leveled to other similar hardware just by a software development method, which does not directly produce any good to me.