Synthesizing Device Drivers

1. Synthesizing Device Drivers Roumen Kaiabachev and Walid Taha Department of Computer Science, Rice University Problems of a More Complex Driver For Continuous Data Acquisition Operating systems depend on device drivers to communicate with attached hardware. A device driver is a collection of subroutines written in a low-level language that interact both with the operating system and the actual device. Driver Development is Hard • Resource tracking. It is not allowed to start an acquisition at the same time another is already running. Also, it is invalid to read data or stop an acquisition if none is running. Buffering. Data acquired continuously is buffered until the application can process it. Data is transferred in the background from a small hardware buffer on the device to a second, larger buffer in computer memory. B A Why? Driver code executes in the operating system trusted kernel. When driver code crashes, the whole system is usually taken down. • Wait strategy. There are a number of ways the driver can wait when requested data is not yet available: polling, yielding, sleeping, and waiting for an interrupt. Page locking. Memory accessed from an interrupt-service routine (ISR) or as part of a direct memory access transfer must be "page-locked" to prevent pages from being swapped out. C D How? We want to use high level declarative specifications to generate device drivers which model operating system processes and correctly communicate with the hardware.  We are building infrastructure in the form of a domain-specific language (DSL) which will provide the formal theory and software engineering medium for development of device drivers. • Atomic device access. The device can be accessed from both the ISR and from a user process calling device code. These device accesses can be concurrent. We have to guarantee the ISR an atomic access until it is done unless it is interrupted by a higher priority interrupt. E F • Buffer overflow. There is a condition when the buffer can overflow. • Bad parameters. The user could give wrong parameters to the device. • Handling device reset. The driver should support a reset function that stops any ongoing acquisition and returns the device to an initial state. The Windows 2000 Architecture G H • We Studied a Number of Existing Tools • Cyclone – statically typed safe dialect of C • Devil – DSL, high-level definition of bit-mapped I/O • NDL – DSL, state-machine-based model of device resources and common device driver operations • BLAST – software model checking • In a previous study, we wrote a tiny device driver in each of the tools to see how much and to what extentthey can help. There were several useful techniques to take. • We are Designing and Implementing a DSL, RIDL that solves the problems of the driver. • We will use state to tackle • We will use types for safe locking and will explicitly model an interrupt scheduler (constraints will be applied from defined scheduling requirements). • We will use Devil-like interface checking for • RIDL will also use a Blast-like approach to guarantee that certain user-specified states cannot be reached. Acknowledgements: This work is supported by National Instruments, Schlumberger, and a Texas ATP grant A B C D F H • Handling Other Driver Problems • We will expand RIDL to handle other interesting device driver paradigms and make it a useful tool for driver writers. E G