linux device drivers l.
Skip this Video
Loading SlideShow in 5 Seconds..
Linux Device Drivers PowerPoint Presentation
Download Presentation
Linux Device Drivers

Loading in 2 Seconds...

play fullscreen
1 / 24

Linux Device Drivers - PowerPoint PPT Presentation

  • Uploaded on

Linux Device Drivers. Inroduction. 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

Linux Device Drivers

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    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!