A Comparative Study of Device Driver Towards a Uniform Approach

Wadih Zaatar and Iyad Ouaiss Lebanese American University Byblos, Lebanon [email protected]

Abstract to providers of open source technologies such as RedHat, Mandrake, Suse, essentially tar- geted towards the Linux platform or NewBus Linux Application Program Interfaces (APIs) toward the platform [OpSys] [LinDriv] lack stability and standardization. There is [NTDriv] [DrivDes]. Other solutions proposed a need for a standard API for Linux device by some companies such as WinDriver, would drivers that allow backward compatibility allow you to get a shareware Graphical while easing the development of new drivers. (GUI) to build your set of drivers with The advantage of standardizing the API is prewritten code to get you started. Recently, to make the kernel core more robust and the an interesting approach with a mixed hardware development of new drivers easier; however and solution named I2O comes with the main challenge is performance-based. This another innovative concept that would be ex- work starts by carefully studying the available plained later in Section 3.1. Therefore, we can APIs for Linux as well as for other platforms. see that there exists a multitude of different so- Current solutions studied include the Uniform lutions for the problem, each with its own set Driver Interface (UDI), the Intelligent I/O of advantages and disadvantages. architecture (I2O), WinDriver, and APIs implemented in Solaris, and Windows XP. This paper does not pretend to give a final so- By listing the strengths and weaknesses of lution to the problem; it simply tries to clas- available APIs, a proposal for a new Linux sify all the currently available models into cat- API is constructed that defines a standard egories and proposes a draft of a work matrix interface, provides backward compatibility, for an improved device driver interface. But ensures kernel security, and handles errors, proposing a solution requires a small introduc- uniform block sizes, buffering, etc. tion on how device drivers operate in general and Linux in particular:

A device driver is essentially a kernel com- 1 Introduction ponent, but is developed independently form the rest of the kernel. Therefore, there should be some kind of interfacing service between Device driver implementations have always the driver and the host . A been an important field of study in the world standard implementation would have two in- of operating systems from proprietary mod- terfaces: The first one would communicate els of companies such as Sun and Ottawa Linux Symposium 2002 408 Application Kernel32.dll with the hardware itself, namely the Driver- NTdll.dll Hardware interface and the second one would take care of communicating with the operat- ing system and of course the user, called the Driver-Kernel interface. This is where the User Mode problem really resides: Due to several causes Kernel Mode NtCreateFile (architecture, OS and hardware differences), it NtReadFile is really rare to find a piece of software to be bi- KiSystemService nary portable between two different machines, and thus nearly impossible to have some device Nt Close driver (which is after all just a small specialized program) to run on different , run- System Service Table ning different operating systems. This is where Figure 1: Windows API Model layering and abstraction come handy: by an- alyzing all common components of devices, one could come up with a standard, platform- independent API that would group all repeti- operating systems, namely tive system calls. This solution has two main and Linux/Unix main implementations along- advantages: unify device driver implementa- side some third-party commercial and public tion, which will lead to faster development and license developers. better code reuse, but also would guarantee on the long run platform independence; and, in the 2.1 Microsoft Windows API case of API would allow old device drivers to benefit from the new API. Microsoft’s device driver API [MSModel1] [MSModel2] were gradually enhanced with The following sections describe the currently every new OS release, reaching a good level of available API implementations, starting with stability due to two important factors: the first proprietary API with Microsoft and Sun, inde- being software maturity starting from Win- pendent implementations with WinDriver and dows 3.0 until the latest release of Windows UDI, and finally, a new approach towards solv- XP based on NT technology, and second due ing the problem with the I2O architecture that to Microsoft’s device driver compliance pro- encompasses both hardware and software com- gram that would take every device driver for ponents. The final section will recapitulate all any new hardware, run it and make sure that it advantages and disadvantages of every API im- is stable enough to be released with a “Certifi- plementation, giving a skeleton for a work ma- cate of Compliance” for it to be properly inte- trix and proposing a primary set of steps that grated with the latest OS release. This signifi- will guide the development of a Linux device cantly reduced erratic OS crashes and restarts driver API that meets the requirements set forth that made Windows platforms untrustworthy in this paper. amongst the IT community. This model is de- picted in Figure 1.

2 Review of Software Approaches To be Microsoft-certified, a device driver has to have the following features: The following section describes the different API implementations for the most widely used • Handle I/O requests in standard format. Ottawa Linux Symposium 2002 409

• Be object-based following the Windows 2.2 Sun Solaris API model. • Allows plug and play devices to be dy- In System V Release 4 (SVR4), the in- namically added or removed. terface between device drivers and the rest of the UNIX kernel has been standard- • Allow power management. ized and completely documented [SunModel1] [SunModel2]. These interfaces are divided into • Be configurable in terms of resources. the following subdivisions: • Be multiprocessor code reentrant. • Be portable across all Windows platforms. • The Device Driver Interface/Driver Ker- nel Interface (DDI/DKI) that includes architecture-independent interfaces sup- From these major points, we can draw the fol- ported on all implementations of System lowing advantages: V Release 4 (SVR4).

• Windows drivers are portable between all • The Solaris DDI that includes platforms, as part of their requirements. architecture-independent interfaces specific to Solaris. • Customizable as they are object based. • The Solaris SPARC DDI that includes • Support new technology such as PnP and SPARC Instruction Set Architecture Power Management. (ISA) interfaces specific to Solaris.

Are these really applied in reality? According • The Solaris x86 DDI that includes x86 In- to Microsoft themselves, their device model struction Set Architecture (ISA) interfaces suffers the following: specific to Solaris. • The Device Kernel Interface (DKI) • System instability: since they are run in that includes DKI-only architecture- kernel mode, and thus not isolated from independent interfaces specific to SVR4. one another or from the operating system, These interfaces may not be supported in a failure in any device driver would result future releases of System V. in system instability or a blue-screen.

• Little abstraction: the device driver inter- The Solaris 2.x DDI/DKI allows platform- face is very low level and as such, there is independent device drivers to be written for little abstraction of the inner workings of SunOS 5.x based machines. These drivers the exported functions. This means that would allow third-party hardware and software the device driver developer has to under- to be more easily integrated into the OS. Fur- stand more about the workings to the in- thermore, it is designed to be architecture in- terface than probably necessary. dependent and allow the same driver to work across a diverse set of machine architectures. • Plug and Play implementation: the PnP The following main areas are addressed: implementation is entirely set on the pro- grammer’s shoulders, requiring additional synchronizations and thus extra overhead. • handling. Ottawa Linux Symposium 2002 410

User Application Application Programs I/O Requests User Driver Code

WinDriver Operating System UserMode Library UDI Environment User Mode Interfaces Kernel Mode Portable Kernel Plug−In System I/O Device Configuration User WinDriver Performance WinDriver − Kernel User Hardware Drivers Diagnostics Critical Kernel PlugIn Functions Error Handling System Services Figure 2: WinDriver Model Hardware I/O Interface

• Accessing the device space from the ker- CPU and I/O Hardware Interrupts nel or a user (register mapping and memory mapping). Figure 3: Uniform Device Driver Interface Model • Accessing kernel or user process space from the device (DMA services).

• Managing device properties. source code with initial procedure defini- tion, global variables and program entry- points and basic calls. 2.3 WinDriver From these features, we can deduce the follow- The WinDriver API is a commercial, OS in- ing list of advantages: dependent approach toward a common device driver API [WDModel]. WinDriver has the fol- • Cross platform compatibility and code lowing important features: reuse: No need for re-writing new drivers for the same hardware when porting to • Source code compatibility between all different architectures. supported operating systems: Windows, • Minimal performance hit: WinDriver of- Linux, Solaris and VxWorks. fers a plug-in that would run performance • Binary code compatibility between all critical parts right into the kernel, thereby Windows flavors (95, 98, Me, NT4, 2000, achieving kernel mode performance. XP). • Easy drivers programming: WinDriver supports generic code generation in sev- • Supports numerous architectures (PCI, eral programming languages, namely E/ISA, and USB). C/C++ and Delphi. • Rapid device driver programming through the availability of many wizards. These 2.4 Uniform Device Driver Interface wizards allow the device driver program- mer, through a series of GUI-oriented The Uniform Device Driver Interface (UDI) is steps to build the skeleton of the driver another initiative to create an architecture, plat- Ottawa Linux Symposium 2002 411

I2O Architecture form, and OS independent solution for device Traditional drivers [UDIModel]; it is depicted in Figure 3. Host * Implementation− Indepedent Layer OSM Similar to WinDriver, UDI has the following Implementation− * OS Specific * Enables Node−Node features: Specific OS * OS Revision Communication Driver Code Independent IOP Communication Layer Implementation− • Platform neutrality, it abstracts all PIOs, Specific HDM DMAs, and interrupt handling through a (Host or IOP) * OS Independent Code * I/O Software set of interfaces that hide all architectures’ variations. Hardware Hardware • Drivers are written in ISO standard C and do not use any compiler specific exten- Figure 4: I2O Architecture Model sions.

• UDI imposes shared memory restrictions, 3.1 The I2O Architecture allowing system isolation of the driver code from the remainder of the OS, im- proving reliability and debuggability. The I2O Architecture model is depicted in Fig- ure 4. • Strict versioning allows evolution of the interfaces while preserving full binary Contrary to the standard implementation that compatibility of existing drivers. relies on the host CPU to process all inter- rupt requests, the I2O eliminates processing bottlenecks by alleviating these tasks from The UDI device driver implementation is very the processor and taking care of them di- much similar to WinDriver; therefore one rectly [I2OModel]. could expect the following advantages: The I2O defines three software layers:

• Cross platform compatibility, noting that UDI supports a narrower range of operat- • The OS Services Module (OSM), that ing systems. handles the communication between the host CPU operating system and device • Performance is comparable to native I/O class. drivers due to the fact that the code ex- ecutes in kernel space, allowing minimal • The I2O Messaging Layer that handles performance degradation. communication between the OSM and HDM in as standard way (see Figure). 3 Review of Mixed Approaches The standard I2O messaging layer does away the current requirement for OEMs to develop multiple drivers for the same The following section presents a new approach device. towards solving the device drivers’ incompati- bilities: By proposing a software and hardware • The Hardware Device Module (HDM) components instead of a unique software ap- handles the communication between the proach. device and the I2O messaging Ottawa Linux Symposium 2002 412

layer. The HDM is unique for each de- software solutions specify in their imple- vice. However, unlike a traditional device mentation the need for memory protec- driver, only one HDM is required because tion. it is independent of the host CPU operat- ing system. • Compatibility: Despite the Microsoft re- quirement that drivers should be upward compatible. Some tests performed on The I2O implementation offers the following Microsoft Windows 2000 based drivers improvements over traditional I/O processing: would erratically crash the system if in- stalled on Windows XP, which would • Standardized extensible architecture that prove that these drivers still have compat- is OS independent. ibility issues. WinDriver and UDI drivers • Increased reliability and fault isolation to are still under test. The I2O alternative improve stability. seems excellent on paper but for the same reason as described above, no tests were • Provides optimized I/O and system per- performed. formance because the I/O process can be managed directly. • Portability: WinDriver is the most versa- tile as it would run under most operating 4 Analysis systems and is fully source compatible, a simple recompilation being enough. This would be ideal for multi-OS based solu- Based on the previous sections, we can draw tions. UDI follows the lead with fewer comparative measures that encompass all cur- but still promising implementations. The rently available solutions. The work matrix is Windows and Solaris API models are pro- shown in Table 1. prietary and as such are not portable. The following criteria were selected to distin- guish between all available solutions: 5 Conclusion

• Performance: It is an essential compo- This paper represents the results of a data col- nent in any comparative study; however lection operation performed in order to ana- the measurement factor was much debated lyze available device driver implementations during the analysis of every solution. The for several operating systems. Many parame- number of interrupts per second that could ters still have to be exploited and carefully in- be processed was finally selected. But due vestigated. Most importantly, the performance to the difficult nature of the task, this work factor that would gear towards choosing one is still taking an important amount of time solution over another is still being debated. and still not completed. One important With a better understanding of device driver note: The I2O group ceased operation and APIs, the qualities and importance of each fea- it was not possible to get access to any I2O ture in the API and its role in the operating sys- based chips for testing. tem can be analyzed. The next step in this re- • Security: This parameter describes the search effort is to select a set of features that various security-related issues in every so- can be bundled together in order to form a com- lution, memory-protection, and recover- pact, robust, and efficient Linux device driver ability after a driver crash, etc. All four API. Ottawa Linux Symposium 2002 413

Security Compatibility Portability Notes Windows Microsoft Problems Windows, Generic API Binary Solaris Sun Yes SunOS Generic API Binary Win To be Yes All, Commercial Driver tested Source UDI To be Yes Most, Freeware tested Source I2O Hardware Hardware All, Discontinued Independent

Table 1: Comparison Matrix

6 Acknowledgments /PSummaryIT.pl?paperid= 20024&scid=273

The authors would like to thank the students [MSModel2] Windows Device Drivers who participated in this work: Jamal Maalouf, Architecture. Fady Matar, Naji Charbel, Francois Nader, and http://www.itpapers.com/cgi Elie Hajj. /PSummaryIT.pl?paperid= 13052&scid=273

References [SunModel1] Porting to Solaris 2.X, Sun Whitepaper. [OpSys] Andrew S. Tanenbaum, Modern http://sunsite.nstu.nsk.su/sun Operating Systems, 2nd Edition, Prentice /inform/whitepapers.html Hall. (2001). [SunModel2] An Engineering Tutorial on [LinDriv] Alessandro Rubim and Jonathan Porting your Device Driver to Solaris Corbet, Linux Device Drivers, 2nd 2.0, Sun Whitepaper. Edition, OReilly. (2001). http://sunsite.nstu.nsk.su/sun /inform/whitepapers.html [NTDriv] Edward N. Dekker and Joseph M. Newcomer, Developing Windows NT 4.0 [WDModel] Jungo Ltd. Device Drivers, Addison Wesley http://www.jungo.com Longman. (1998). /windriver.html

[DrivDes] Introduction to Device Driver [UDIModel] Uniform Driver Interface, Design. http://www.itpapers.com Official Specification Documents /cgi/PSummaryIT.pl?paperid= http://www.project-UDI.org 9103&scid=264 /specs.html

[MSModel1] Windows Driver Model: [I2OModel] Pauline Shulman, Overview of Compatible Drivers for Microsoft the I2O Architecture. PC Developer Windows Operating Systems. Conference. (1998). http://www.itpapers.com/cgi Proceedings of the Ottawa Linux Symposium

June 26th–29th, 2002 Ottawa, Ontario Canada Conference Organizers Andrew J. Hutton, Steamballoon, Inc. Stephanie Donovan, Linux Symposium C. Craig Ross, Linux Symposium

Proceedings Formatting Team John W. Lockhart, Wild Open Source, Inc.

Authors retain copyright to all submitted papers, but have granted unlimited redistribution rights to all as a condition of submission.