Solving the starting problem: device drivers as self-describing artifacts

  • Authors:

  • Michael F. Spear;Tom Roeder;Orion Hodson;Galen C. Hunt;Steven Levi

  • Affiliations:

  • University of Rochester, Rochester, NY;Cornell University, Ithaca, NY;Microsoft Research, Redmond, WA;Microsoft Research, Redmond, WA;Microsoft Research, Redmond, WA

  • Venue:
  • Proceedings of the 1st ACM SIGOPS/EuroSys European Conference on Computer Systems 2006
  • Year:
  • 2006

Quantified Score

Hi-index 0.02

Visualization

Abstract

Run-time conflicts can affect even the most rigorously tested software systems. A reliance on execution-based testing makes it prohibitively costly to test every possible interaction among potentially thousands of programs with complex configurations. In order to reduce configuration problems, detect developer errors, and reduce developer effort, we have created a new first class operating system abstraction, the application abstraction, which enables both online and offline reasoning about programs and their configuration requirements.We have implemented a subset of the application abstraction for device drivers in the Singularity operating system. Programmers use the application abstraction by placing declarative statements about hardware and communication requirements within their code. Our design enables Singularity to learn the input/output and interprocess communication requirements of drivers without executing driver code. By reasoning about this information within the domain of Singularity's strong software isolation architecture, the installer can execute a subset the system's resource management algorithm at install time to verify that a new driver will not conflict with existing software. This abstract representation also allows the system to run the full algorithm at driver start time to ensure that there are never resource conflicts between executing drivers, and that drivers never use undeclared resources.