NDL: A Domain-Specific Language for Device Drivers Christopher L. Conway Stephen A. Edwards [email protected] [email protected] Department of Computer Science, Columbia University 1214 Amsterdam Ave., New York, NY 10027 1 ABSTRACT To address this challenge, we introduce NDL , a domain- Device drivers are difficult to write and error-prone. They specific language for device drivers. The language includes are usually written in C, a fairly low-level language with direct support for the semantics of device drivers, leading to minimal type safety and little support for device semantics. shorter, more maintainable driver code. NDL can be used As a result, they have become a major source of instability to write drivers for a wide variety of devices in a platform- in operating system code. neutral fashion. The compiler is designed to be readily This paper presents NDL, a language for device drivers. ported to a broad class of operating systems. NDL provides high-level abstractions of device resources and In this paper, we demonstrate the features that make NDL constructs tailored to describing common device driver op- device drivers simple and concise and show that the NDL erations. We show that NDL allows for the coding of a se- compiler produces code which is only marginally less effi- mantically correct driver with a code size reduction of more cient than the equivalent C. Throughout this paper, we will than 50% and a minimal impact on performance. illustrate the use of NDL using examples from the driver for an NE2000-compatible Ethernet adapter. Categories and Subject Descriptors 2. RELATED WORK Programming Languages D.3.3 [ ]: Language Constructs A variety of approaches have been suggested to improve and Features|domain-specific languages; D.1.2 the reliability of low-level software and device driver soft- Programming Techniques [ ]: Automatic ware in particular. Crary and Morrissett [3] propose typed Software Programming|program synthesis; D.2.3 [ assembly language as a compiler target for preserving type Engineering ]: Coding Tools and Techniques information from higher-level languages. Unfortunately, C, the most common systems programming language, is not General Terms much more strongly typed than a traditional assembly lan- Design,Languages,Reliability guage; there is little the compiler can do to improve the type safety of C code. Deline and F¨ahndrich [4] use a similar typing system in Keywords the C-like programming language VAULT. The use of vari- Device drivers, systems programming, domain-specific ables is controlled through type guards that describe when languages an operation on a variable is valid. In order for the compiler to accept the program, it must respect the type guards' ac- 1. INTRODUCTION cess specifications and types must match at program join points. VAULT has shown some success in preventing com- Device drivers are critical, low-level systems code. Tra- mon programmer errors, but its limitations on alias types ditionally, they have been written in C due to its efficiency prevent it from being generally applicable to device driver and flexibility. Unfortunately, sophisticated device interac- development. tion protocols and C's lack of type safety make driver code Holzmann [5] and Ball and Rajamani [1] have addressed complex and prone to failure. Indeed, device drivers have the use of static analysis in the verification of traditional C been noted as a major source of faults in operating system systems software. Static analyses can find subtle bugs and code [2]. However, no other high-level language is widely increase confidence in the code, but the types of detectable accepted for device programming. errors are restricted and the quality of the analysis depends on programmer-written property specifications. A group at the University of Rennes has done perhaps the most work on domain-specific languages for device drivers. Permission to make digital or hard copies of all or part of this work for Thibault et al.'s GAL [8] is a domain-specific language for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies X Windows video drivers. Their compiler combines a par- bear this notice and the full citation on the first page. To copy otherwise, to tial evaluation framework with a language tailored to video republish, to post on servers or to redistribute to lists, requires prior specific driver operations to produce driver code that is nearly 90% permission and/or a fee. 1 LCTES'04, June 11–13, 2004, Washington, DC, USA. With apologies to GNU, NDL stands for \The NDL Device Copyright 2004 ACM 1-58113-806-7/04/0006 ...$5.00. Language". smaller than the equivalent C code and just as fast. This start = true; work is promising, but the methodology may not be appli- dmaState = DISABLED; cable to a wider variety of device drivers. remoteDmaByteCount = count; Also at Rennes, M´erillon et al. [6] developed Devil, an interface definition language designed to be a more general NDL also provides a mechanism for describing groups solution for device driver development. A Devil specifica- of mutually exclusive states and procedures for switching tion describes hardware components such as I/O ports and among them. As a result, with a single line of NDL code memory-mapped registers. The specification is compiled the programmer is able to effect a state transition that would into a set of C macros for device manipulation; the macros require many I/O operations in an equivalent C program. are called from traditional C driver code, allowing the driver Copying large amounts of data to and from buffers is an- programmer to avoid writing the lowest-level code by hand. other frequent device operation. There are common idioms This approach prevents certain common programming er- for a buffer-to-buffer copy in C, but they are complicated by rors, but it does not specify the protocol for using the device, the need to support compatible devices with different data and it does not provide the type safety of a higher-level so- bus widths in the same driver. NDL treats buffer copy- lution. Nevertheless, portions of NDL borrow liberally from ing as a special case of assignment. The following fragment Devil's interface definition syntax. reads count bytes read from the FIFO dataport (defined O'Nils and Janstch [7] and Wang et al. [9] have also devel- elsewhere) and placed in the array buffer using the appro- oped tools for device driver synthesis, but they are primar- priate I/O operations. ily concerned with hardware/software codesign for embed- var buffer: byte[count]; ded systems. NDL provides a more flexible tool for a wider buffer = dataport; range of devices. 3.1 Device Inheritance 3. NDL An NDL driver may begin by declaring a parent device NDL is a language for device driver development that from which it should inherit interface and template infor- provides high-level constructs for device programming, de- mation. For example, the NE2000 driver declares itself as scribing the driver in terms of its operational interface. Its an extension of NetworkDevice, which is an abstract device declarations are designed to closely resemble the specifica- that defines functions and variables common to all Ethernet tion document for the device it controls. An NDL driver adapters, such as the start transmit function, which takes is typically composed of a set of register definitions, proto- a packet buffer and queues it for transmission. cols for accessing those registers, and a collection of device In addition, NetworkDevice is associated with a template functions. The compiler translates register definitions and that specifies the boilerplate code required to implement a access protocols into an abstract representation of the de- network driver on a particular platform (e.g., initialization vice interface. Device functions are then translated into a and release of operating system data structures and requests series of operations on that interface. for system resources). Templates provide the glue layer Device drivers are systems-level code that interact directly between the high-level device specification and platform- with the operating system. The NDL compiler generates C specific C driver code. that makes appropriate operating system calls. Platform- specific functions are provided through compiler libraries 3.2 Device States and device templates; platform dependencies are minimal. Often, aspects of a device's behavior are most easily mod- NDL's main abstraction is a representation of the state eled as finite-state machines. For example, the direct mem- of the peripheral device being controlled. Internally, de- ory access system in the NE2000 can be either transferring vices can be in a variety of states, e.g., receiving data, wait- data to the card, from the card, or can be idle. NDL sup- ing for a certain condition, or having encountered an error. ports this view through explicitly defined state machines, From software, this state can be fairly awkward to access. such as those in Figure 1. A state machine is defined as At its simplest, it is spread out across bits in I/O memory a list of mutually exclusive states separated by `||'. Each packed carefully into bytes. Typically it is even more com- state may have a an associated list of statements intended plicated, often consisting of an address and data register pair to switch the machine to that state, invoked when a corre- that provide indirect access to internal device registers. In sponding goto statement is executed. both cases, NDL provides an abstraction layer that provides The states STOPPED and STARTED are mutually exclusive. transparent access to this state information. When the device needs to enter the STOPPED state, the state- For example, a typical sequence of I/O memory accesses ments \goto DMA DISABLED" (indicating a transition to state in C might be coded DMA DISABLED) and \stop = true" will be executed.