An empirical study of operating systems errors
SOSP '01 Proceedings of the eighteenth ACM symposium on Operating systems principles
Thorough static analysis of device drivers
Proceedings of the 1st ACM SIGOPS/EuroSys European Conference on Computer Systems 2006
Devil: an IDL for hardware programming
OSDI'00 Proceedings of the 4th conference on Symposium on Operating System Design & Implementation - Volume 4
Windows XP kernel crash analysis
LISA '06 Proceedings of the 20th conference on Large Installation System Administration
Proceedings of the 4th ACM European conference on Computer systems
Tolerating hardware device failures in software
Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles
Automatic device driver synthesis with termite
Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles
Testing closed-source binary device drivers with DDT
USENIXATC'10 Proceedings of the 2010 USENIX conference on USENIX annual technical conference
Correct-by-construction generation of device drivers based on RTL testbenches
Proceedings of the Conference on Design, Automation and Test in Europe
Hi-index | 0.01 |
Faulty device drivers are a major source of operating system failures. We argue that the underlying cause of many driver faults is the separation of two highly-related tasks: device verification and driver development. These two tasks have a lot in common, and result in software that is conceptually and functionally similar, yet kept totally separate. The result is a particularly bad case of duplication of effort: the verification code is correct, but is discarded after the device has been manufactured; the driver code is inferior, but used in actual device operation. We claim that the two tasks, and the software they produce, can and should be unified, and this will result in drastic improvement of device-driver quality and reduction in the development cost and time to market. In this paper we discuss technical issues involved in achieving such unification and present our solutions to these issues. We report the results of a case study that applies this approach to implement a driver for an Ethernet controller device.