Linux Device Drivers

1. Linux Device Drivers Inroduction

2. What’s a ‘device-driver’? • A special kind of computer program • Intended to control a peripheral device • Needs to execute ‘privileged’ instructions • Must be integrated into the OS kernel • Interfaces both to kernel and to hardware • Program-format specific to a particular OS

3. Linux device-drivers • A package mainly of ‘service functions’ • The package is conceptually an ‘object’ • But in C this means it’s a ‘struct’ • Specifically: struct file_operations { …; }; • Definition is found in a kernel-header: ‘/usr/src/linux/include/linux/fs.h’

4. Types of Device-Drivers • Character drivers: - the device processes individual bytes (e.g., keyboard, printer, modem) • Block drivers: - the device processes groups of bytes (e.g., hard disks, CD-ROM drives)

5. Linux has other driver-types • Network drivers • Mouse drivers • SCSI drivers • USB drivers • Video drivers • ‘Hot-swap’ drivers • … and others

6. Linux treats devices as files • Programmers accustomed to the file API open(), seek(), read(), write(), close(), ... • Requires creating a filename in a directory (special ‘/dev’ directory is for devices)

7. Driver Identification • Character/Block drivers: • Use ‘major-number’ to identify the driver • Use ‘minor-numbers’ to distinguish among several devices the same driver controls • Kernel also needs a driver-name • Users need a device-node as ‘interface’

8. Developing a device-driver • Clarify your requirements • Devise a design to achieve them • Test your design-concept (‘prototype’) • ‘Debug’ your prototype (as needed) • Build your final driver in iteratively • Document your work for future use

9. ‘Open Source’ Hardware • Some equipment manufactures regard their designs as ‘intellectual property’ • They don’t want to ‘give away’ their info • They believe ‘secrecy’ is an advantage • They fear others might copy their designs • BUT: This hinders systems programmers!

10. Non-Disclosure Agreements • Sometimes manufacturers will let ‘trusted’ individuals, or commercial ‘partners’, look at their design-specs and manuals. • College professors usually are ‘trusted’ • BUT: Just to be sure, an NDA is required -- which prevents professors from teaching students the design-details that they learn.

11. Advantage of ‘open’ designs • Microsoft and Apple used to provide lots of technical information to programmers. • They wanted to encourage innovations that made their products more valuable. • Imagine hundreds of unpaid ‘volunteers’ creating applications for your system! • BUT: Were they ‘giving away the store’?

12. Some designs are ‘open’ • The IBM-PC designs were published • Other companies copied them • And those companies prospered! • While IBM lost market-share! • An unfortunate ‘lesson’ was learned

13. Standard PC/AT Keyboard Controlling the three LEDs

14. References on PC keyboard • Hans-Peter Messmer, “The Indispensable PC Hardware Book (Third Edition)”, Addison-Wesley (1997), pp. 1007-1030. • Frank van Gilluwe, “The Undocumented PC (Second Edition)”, Addison-Wesley (1997), pp. 309-390.

15. 8042 Keyboard Controller • Programming Interface (4 registers): control register (0x64, write-only) status register (0x64, read-only) input buffer register (0x60, write-only) output buffer register (0x60, read-only) • Device Interface (2 registers + 2 signals): input port register timing signals output port register interrupt signals

16. Keyboard Controller’s Status • Eight individual status-bits (read-only) • Visible to cpu by using: ‘inb( 0x64 ); bit #0: output-buffer full bit #1: input-buffer full • Other bits are unimportant for LEDs

17. Two-Step Sequence • Step 1: Send command-byte • Step 2: Send parameter-byte • If this sequence were to interrupted, then another process might try to send a byte, causing hardware to perform wrong action!

18. “Critical Section” • Code-fragment whose correct functioning depends on it not being interrupted • Subject to “race conditions” if exclusive access to resourses isn’t assured

19. On Uniprocessor Systems • Disable interrupts during “critical section”: cli(); // do not recognize interrupts … /* critical code-fragment goes here */ … sti(); // ok to recognize interrupts

20. Algorithm for setting LEDs • Block interrupts (Enter “Critical Section”) • Wait till controller’s input-buffer empties • Output the ‘write_LED’ command-byte • Wait till controller’s input-buffer empties • Output the LED indicator-byte • Wait till controller’s input-buffer empties • Allow interrupts (Leave “Critical Section”)

21. On Multiprocessor Systems • Not enough to block interrupts on one cpu • Must also insure other cpus can’t interfere

22. Module ‘Boilerplate’ • Must have ‘init_module()’ function (to ‘register’ service-functions with kernel) • Must have ‘cleanup_module()’ function (to ‘unregister’ your service-functions)

23. More ‘boilerplate’ • Must include certain kernel header-files (e.g., #include <linux/module.h>) • Must define certain constants (e.g., #define __KERNEL__, MODULE)

24. Rapid Prototyping • We will be writing lots of modules • We can ‘automate’ the boilerplate • We should write a ‘wizard’ program • It will save us LOTS of time!