Avoiding the OS abstraction trap

Posted Aug 14, 2011 16:01 UTC (Sun) by bfields (subscriber, #19510)
In reply to: Avoiding the OS abstraction trap by ebirdie
Parent article: Avoiding the OS abstraction trap

"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.