Catalyzing Open Driver Development

Hardware driver support is perhaps one of the most difficult hurdles to overcome in the march towards world domination. Unfortunately, getting that support for Linux(R) is not always a trivial task.  This process involves, at a minimum, coordination between Linus' patch lieutenants and the hardware vendors' engineering and legal departments; on a more practical level, the hardware vendors need to build and maintain good communication channels with the various distributions to gather feedback and to solve problems. We participate in those complex interactions to catalyze the development process, and build open source alternatives when that fails. For this presentation, we offer four examples of this catalytic process, and discuss the task of helping hardware vendors to merge functionality, when possible, from an internal driver release train into mainline.

In the first case, we discuss how ongoing maintenance and enhancement work with
the longtime mainline resident pcnet32 driver progresses without much hand-holding from AMD(R) , the original hardware vendor; the case details the traditional process of collaborative driver development among many enthusiasts. The second case explores working with Adaptec(R) to evaluate, diagnose, and resolve performance issues with the aacraid driver and ongoing work to clean up widespread confusion in comparing versions of the driver. With regards to the third case, we discuss assistance given to Adaptec to address issues blocking the aic94xx Serial Attached SCSI driver from entering mainline.  In the final case, we discuss negotiating with Adaptec for hardware behavior specifications, implementing a HostRAID(R) plugin for dmraid (presented at OLS 2005), altering device-mapper to make grub work better, and assisting the distributions to support installation and booting off of a dmraid device.