Introduction

 

Device drivers commonly execute in the kernel to achieve high performance and easy access to kernel services.

 

This paper introduces the Microdrivers architecture that achieves high performance and compatibility by leaving critical path code in the kernel and moving the rest of the driver code to a user-mode process.

 

Executing drivers in user mode provides several important benefits

 - driver developers can take advantage of user mode tools such as profilers, libraries, scripting languages and advanced debuggers

 - the user/kernel boundary isolates the kernel from driver failures

 

However, existing user mode drivers frameworks suffer from one of two problems

 - previous attempts to execute unmodified drivers in user mode performed poorly

 - user mode driver frameworks that achieve high performance require complete rewrites of the driver

 

The result is a new architecture for device drivers that we call Microdrivers. A microdriver is a device driver that is split into a kernel-level k-driver and a user-level u-driver. This architecture yields four concrete benefits over traditional kernel drivers.

  1. user-level programming
    1. The u-driver can be compiled and debugged with standard user-mode tools
  2. good common-case performance
    1. Microdrivers have common case performance comparable to traditional device drivers and better than kernel driver code executing fully in user mode.
  3. Fault isolation
    1. Microdrivers isolate faults better than traditional device drivers, because a buggy u-driver will not crash the entire system.
  4. Compatibility
    1. Microdrivers are compatible with commodity operating systems

 

DriverSlicer's splitter partitions driver code such that performance critical functions remain in the kernel.

DriverSlicer's code generator emits marshaling code to pass data between the microdriver components. Unlike traditional marshaling code for RPC, this tool employs static analysis to reduce the amount of data copied.

 

We evaluate the Microdrivers architecture and DriverSlicer on drivers from the Linux 2.6.18.1 kernel.

  1. U-Drivers can be written and debugged with common user-level programming tools
  2. Micro drivers achieve common-case performance similar to native kernel drivers
  3. Microdrivers isolate failures in the u-driver from the kernel
  4. Microdrivers reduce the amount of driver code running in the kernel


+ Recent posts