1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

A Call To "Kill All Proprietary Drivers For Good"

Michael Larabel

Published on 29 March 2012
Written by Michael Larabel
Page 1 of 2 - Comment On This Article

UPDATE: I have been contacted by Qualcomm PR regarding this expected presentation next week. The content of the Qualcomm Atheros developers was not approved by Qualcomm's legal department and the views to be expressed will be of their own personal beliefs.

Next week at the 6th annual Linux Foundation Collaboration Summit in San Francisco, two Qualcomm Atheros engineers will be speaking about their Linux device driver development experiences and will go as far as calling for all proprietary drivers to be killed for good. They talk not just about killing proprietary drivers for Linux, but for all operating systems. Can the plans they lay out to kill all proprietary drivers work or is this just a big pipe-dream?

Luis R. Rodriguez and Adrian Chadd are the two engineers set to be speaking at the Linux Foundation Collaboration Summit next week Thursday. These engineers from Qualcomm Atheros, yes the company in their pre-Qualcomm days that has had a long and bumpy history in Linux for WiFi support, are promoting that proprietary device drivers be killed. Luis is a Linux hacker at Atheros while Adrian joined the company as a FreeBSD hacker.

First of all, here's their session abstract, "Proprietary drivers have a long history and tradition which has been imposed upon the industry by archaic driver development models and Operating System Vendor requirements. Licensing drivers in a clean way to share with Linux and the BSD families had typically been done under the confusing Dual BSD/GPL tradition. With the 'ath5k wars' and the involvement of the SFLC we've learned a few things to help clarify this and accomplish this in a clean way, but as new driver development continues one of the biggest issues observed is quality of software with proprietary software development models. What are these issues, and how do we fix them? A Linux and FreeBSD developer propose to kill all notions of proprietary drivers practices in the industry for good, not only for Linux, but for all Operating Systems. We'll review how we plan on doing this and would like feedback from the community."

Their path to killing proprietary drivers is easier said then done, but it basically comes down to prioritize clean kernel APIs / code, permissively license Linux kernel drivers, and localize usage of the GPL. If wanting to target *BSD operating system support, pick a BSD and call for unification of BSDs. The Qualcomm employees also provide intellectual property strategies and they promote replacing "internal codebases" in favor of working with upstream Linux and upstream BSD. Further on, if driver code unification is desired, Luis and Adria say to make driver unification become a community problem. These views come from the long Atheros history on Linux and BSDs from the MadWiFi work, Linux rejecting net80211, Linux getting new 802.11 stacks (mac80211 and cfg80211), the Atheros ath5k driver coming about, the ath9k driver is upstreamed in the kernel.

In their LF Collaboration Summit presentation, the developers share that only recently Linux has become a priority on the "desktop" in terms of hardware support at Qualcomm Atheros. They also admit not all free and open-source software projects have good software, software architects can be assholes, and Microsoft and Apple at least has good run-time tests for drivers, validation, and "nice shiny certification logos."

Besides the work of creating the driver, there's also often-overlooked extensive compliance testing, certification work, internal standards / regression testing, specific customer extensions, cross-licensing of patents, and other commercial agreements are among the other challenges they have faced on their Linux/BSD driver work. "These may make it difficult to open up a commercially developed codebase."

Also expressed has been another problem for the hardware vendors and that's for multi-OS drivers and trying to do code-sharing between supported platforms as much as possible to reduce their development efforts as well as their maintenance burden of needing to certify/test multiple stacks. These WiFi driver developers recommend finding a good middle-ground between all of the OS platforms and acknowledge that most companies like to continually reinvent the wheel.

Additionally in their long and evidently passionate views about the topic, the open-source Atheros developers are set to classify crap drivers as those that do not prioritize code readability and long-term maintenance, do not consider an ecosystem for reinventing the wheel on fixing issues, branching hell, the staging area is tainted crap, and that even good drivers can become crap drivers through evolution. Their advice? "Move on, adapt fast, evolve, accept criticism."

After this, Luis R. Rodriguez and Adrian Chadd are set to talk about driver licensing, which comes down to being a call for permissively licensed driver where the code can be shared between operating systems as non-Linux GPL drivers can be a pain in the ass. It's also pointed out that GPL Windows drivers requires MinGW for building (the license for using Microsoft's Windows Device Driver Kit isn't clear for usage on GPL driver source-code) to avoid using the Microsoft DDK. "Better use a fully permissive licensed Linux drivers, share with BSDs."

Latest Linux Hardware Reviews
  1. Intel Xeon E5-1680 v3 & E5-2687W v3 Compared To The Core i7 5960X On Linux
  2. Intel 120GB 530 Series SSD Linux Performance
  3. Btrfs/EXT4/XFS/F2FS RAID 0/1/5/6/10 Linux Benchmarks On Four SSDs
  4. AMD's Windows Catalyst Driver Remains Largely Faster Than Linux Drivers
Latest Linux Articles
  1. NVIDIA vs. Nouveau Drivers With Linux 3.18 + Mesa 10.4-devel
  2. Is The Open-Source NVIDIA Driver Fast Enough For Steam On Linux Gaming?
  3. Linux 3.18 File-System Performance Minimally Changed But Possible Regressions
  4. AMD Radeon Gallium3D Is Catching Up & Sometimes Beating Catalyst On Linux
Latest Linux News
  1. Linux 3.18 Kernel: Not Much Change With Intel Haswell Performance
  2. More File-System Tests Of The Linux 3.18 Kernel
  3. Using NVIDIA's NVENC On Linux With FFmpeg
  4. There's Talk Again About An "Open To The Core" Ubuntu Laptop
  5. PowerVR SGX Driver Code Gets Leaked
  6. V2 Of KDBUS Published For Linux Kernel Review
  7. VirtualBox 4.3.20 Arrives, Still No Sign Of VirtualBox 4.4
  8. Scientific Linux 6.6 vs. Scientific Linux 7.0 Benchmarks
  9. Qualcomm Looks To Get Into The ARM Server Business
  10. HHVM 3.4 Adds New Features, Support
Latest Forum Discussions
  1. Roadmap to Catalyst 14.10 ?
  2. Cant get working Kaveri APU - A10-7850k
  3. Debian Developer Resigns From The Systemd Maintainership Team
  4. Script for Fan Speed Control
  5. Debian Init System Coupling Vote Results
  6. The Slides Announcing The New "AMDGPU" Kernel Driver
  7. Updated and Optimized Ubuntu Free Graphics Drivers
  8. Ubuntu Developers Still Thinking What To Do About Adobe Flash Support