Understanding Modern Device Drivers

Linux driver taxonomy, device driver classes

The above figure, generated using static analysis, shows Linux driver taxonomy in terms of basic driver classes based on the classes, sub-classes, registration with kernel and location. The size (in percentage of lines of code) is mentioned for 5 biggest classes. Not all driver classes are mentioned.

PDF:Get our ASPLOS 2012 paper
Bibtex:Get the Bibtex for citation

We looked at device driver source code using static analysis tools to find out what drivers actually do. We look at how modern research applies to them, how do they interact with the kernel and device, and examine if there are any opportunities to reduce driver code.

Here is what we find (more results and figures in paper):
  • Instead of request handling, surprisingly, the largest contributors to driver code are initialization and cleanup, comprising almost 36% of driver code on average, error handling (5%), configuration (15%), power management (7.4%) and ioctl handling (6.2%). On average, only 23.3% of the code in a driver is dedicated to request handling and interrupts.
  • As devices become increasingly virtualization aware, quick ways to initialize or reset are critical for important virtualization features such as re-assignment of devices and live migration.
  • Drivers contain significant configuration code(15%), specifically in network (33%) and video (28%) drivers. As devices continue to become more complex, driver and OS research should look at efficient and organized ways of managing device configuration
  • Overall, driver code has increased by 185% over the last eight years driven by net/wireless drivers, GPU, media, input devices and virtualization drivers.
  • We find that most driver classes have substantial amounts of device-specific functionality outside class definition i.e. standard interfaces. Code supporting /proc and /sys is present in 16.3% of drivers and comprises over 5.3% of total driver code. Also, 36% of drivers have load-time parameters to control their behavior and configure options not available through the class interface. Additionally, ioctl code comprises 6.2% of driver code, can also cause non-class behavior of drivers.
  • Hence, for 44% of drivers, attempts to recover driver state based solely on the class interface, like shadow drivers [OSDI04] or to synthesize drivers from common descriptions of the class, like Termite [SOSP09], may not work for a substantial number of drivers. Thus, future research should explicitly consider how to accommodate unique behaviors efficiently.
  • We find that 15% of drivers have at least one function that performs processing, and processing occurs in 1% of all driver functions. An even higher fraction (28%) of sound and network drivers do processing.
  • Thus, efforts to generate driver code automatically must include mechanisms for data processing, not just converting requests from the OS into requests to the device. Furthermore, virtualized systems should account for the CPU time spent processing data when this processing is performed on behalf of a guest VM.
  • We also find that 28% of drivers support more than one chipset and these drivers support 83% of the total devices. Any system that generates unique drivers for every chipset or requires per-chipset manual specification may lead to a great expansion in driver code and complexity. Furthermore, there is substantial complexity in supporting multiple chipsets, so better programming methodologies, such as object-oriented programming and automatic interface generation, similar to Devil, should be investigated.
  • We find a variety of interaction styles between drivers and the kernel: drivers with little supporting infrastructure demonstrate frequent interactions with the kernel for access to kernel services but few calls to device support code. Drivers with a high level of abstraction demonstrate few calls to the kernel over all. Drivers with a support library demonstrate frequent calls to kernel generic routines as well as calls to device support routines. Furthermore, a large fraction of driver/kernel interactions are for generic routines (memory, synchronization, libraries) that do not involve other kernel services. Thus, they could be implemented by a runtime environment local to the driver. For example, a driver executing in a separate virtual machine or on the device itself can make use of its local OS for these routines, and drivers in user space can similarly invoke user-space versions of these routines, such as the UML environment in SUD.
  • Interaction with devices: The number and type of device interactions vary widely across devices. Thus, the cost of isolating drivers, or verifying that their I/O requests are correct (as in Nexus) can vary widely across drivers. Thus, any system that interposes or protects the driver/device interaction must consider the variety of interaction styles. Similarly, symbolic execution frameworks for drivers must generate appropriate symbolic data for each interaction style.
  • Interaction with bus: Our results demonstrate that the flexibility and performance of PCI devices comes with a cost: increased driver complexity, and less interface standardization. Thus, for devices that can live within the performance limitations of USB or in a virtualized environment for XenBus, these buses offer real architectural advantages to the drivers. With USB, significant standardization enables less unique code per device, and coarse-grained access allows efficient remote access to devices.
  • Based on our code similarity study, we find that 8% of all driver code is very similar to other driver code. The paper details the similarities found across classes. We find most similarities based on device/kernel wrappers and code within driver from same sub-classes. Finally, we see much of this code can be reduced, by using three methods for achieving this reduction: (i) procedural abstractions for driver sub-classes, (ii) better multiple chipset support and (iii) table driven programming.


Driver study methods

Starts at the common step.

Linux driver study methodlogy




Download full paper here. Citation bibtex here.

More details: Contact Asim Kadav or Prof. Mike Swift.