Linux Device DriversWhat’s a ‘device-driver’?Linux device-driversTypes of Device-DriversLinux has other driver-typesLinux treats devices as filesDriver IdentificationDeveloping a device-driver‘Open Source’ HardwareNon-Disclosure AgreementsAdvantage of ‘open’ designsSome designs are ‘open’Standard PC/AT KeyboardReferences on PC keyboard8042 Keyboard ControllerKeyboard Controller’s StatusTwo-Step Sequence“Critical Section”On Uniprocessor SystemsAlgorithm for setting LEDsOn Multiprocessor SystemsModule ‘Boilerplate’More ‘boilerplate’Rapid PrototypingLinux Device DriversInroductionWhat’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 OSLinux 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’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)Linux has other driver-types•Network drivers•Mouse drivers•SCSI drivers•USB drivers•Video drivers•‘Hot-swap’ drivers•… and othersLinux 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)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’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‘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!Non-Disclosure Agreements•Sometimes manufacturers will let ‘trusted’individuals, or commercial ‘partners’, lookat 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.Advantage of ‘open’ designs•Microsoft and Apple used to provide lotsof technical information to programmers.•They wanted to encourage innovationsthat made their products more valuable.•Imagine hundreds of unpaid ‘volunteers’ creating applications for your system!•BUT: Were they ‘giving away the store’?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 learnedStandard PC/AT KeyboardControlling the three LEDsReferences 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.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 signalsoutput port register interrupt signalsKeyboard Controller’s Status•Eight individual status-bits (read-only)•Visible to cpu by using: ‘inb( 0x64 );bit #0: output-buffer fullbit #1: input-buffer full•Other bits are unimportant for LEDsTwo-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!“Critical Section”•Code-fragment whose correct functioning depends on it not being interrupted •Subject to “race conditions” if exclusive access to resourses isn’t assuredOn Uniprocessor Systems•Disable interrupts during “critical section”:cli(); // do not recognize interrupts…/* critical code-fragment goes here */…sti(); // ok to recognize interruptsAlgorithm 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”)On Multiprocessor Systems•Not enough to block interrupts on one cpu•Must also insure other cpus can’t interfereModule ‘Boilerplate’•Must have ‘init_module()’ function(to ‘register’ service-functions with kernel)•Must have ‘cleanup_module()’ function(to ‘unregister’ your service-functions)More ‘boilerplate’•Must include certain kernel header-files(e.g., #include <linux/module.h>)•Must define certain constants (e.g., #define __KERNEL__, MODULE)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