Device Drivers, Part 1: Linux Device Drivers for Your Girl Friend. This series on Linux device drivers aims to present the usually technical topic in a way that is more interesting to a wider cross-section of readers.
“After a week of hard work, we finally got our driver working,” were Pugs’ first words when he met his girlfriend, Shweta. “Why? What was your driver up to? Was he sick? And what hard work did you do?” Now it was Shweta’s turn to look puzzled, as she replied, “Why ask me? Device Drivers, Part 10: Kernel-Space Debuggers in Linux. Shweta, back from hospital, was relaxing in the library, reading various books.
Ever since she learned of the ioctl way of debugging, she was impatient to find out more about debugging in kernel-space. She was curious about how and where to run the kernel-space debugger, if there was any. Device Drivers, Part 7: Generic Hardware Access in Linux. Device Drivers, Part 6: Decoding Character Device File Operations. Device Drivers, Part 5: Character Device Files. In my previous article, I had mentioned that even with the registration for the <major, minor> device range, the device files were not created under /dev — instead, Shweta had to create them manually, using mknod.
However, on further study, Shweta figured out a way to automatically create the device files, using the udev daemon. She also learnt the second step to connect the device file with the device driver — linking the device file operations to the device driver functions. Here is what she learnt. Automatic creation of device files. Device Drivers, Part 2: Writing Your First Linux Driver in the Classroom. This article, which is part of the series on Linux device drivers, deals with the concept of dynamically loading drivers, first writing a Linux driver, before building and then loading it.
Shweta and Pugs reached their classroom late, to find their professor already in the middle of a lecture. Shweta sheepishly asked for his permission to enter. An annoyed Professor Gopi responded, “Come on! You guys are late again; what is your excuse, today?” Pugs hurriedly replied that they had been discussing the very topic for that day’s class — device drivers in Linux. He explained, “As we know, a typical driver installation on Windows needs a reboot for it to get activated. This impressed the professor.
Dynamically loading drivers These dynamically loadable drivers are more commonly called modules and built into individual files with a .ko (kernel object) extension. Figure 1: Linux pre-built modules Let’s look at the FAT filesystem-related drivers as an example. Figure 2: Linux module operations. Concurrency in the Kernel. As the Linux kernel has grown in complexity to support Symmetric Multi-Processing (SMP) and kernel preemption, more and more scenarios generate multiple threads of execution.
Because threads can simultaneously operate on shared kernel data structures, access to such data structures has to be serialized. In this column, let’s learn the basics of protecting shared kernel resources from concurrent access, starting with a simple example and slowly introducing complexities like interrupts, kernel preemption, and SMP. Spinlocks and Semaphores A code area that accesses shared resources is called a critical section. Spinlocks and semaphores are the two mechanisms used to protect critical sections in the kernel. A spinlock ensures that only a single thread enters a critical section at any time. #include <linux/spinlock.h> /* Initialize */spinlock_t mylock = SPIN_LOCK_UNLOCKED; /* Try to acquire the spinlock. /* … Critical Section … */ /* Release the lock */spin_unlock (&mylock); Device Drivers, Part 4: Linux Character Drivers. This article, which is part of the series on Linux device drivers, deals with the various concepts related to character drivers and their implementation.
Shweta, at her PC in her hostel room, was all set to explore the characters of Linux character drivers, before it was taught in class. She recalled the following lines from professor Gopi’s class: “… today’s first driver would be the template for any driver you write in Linux. Writing any specialised/advanced driver is just a matter of what gets filled into its constructor and destructor…” Device Drivers, Part 9: I/O Control in Linux. “Get me a laptop, and tell me about the x86 hardware interfacing experiments in the last Linux device drivers’ lab session, and also about what’s planned for the next session,” cried Shweta, exasperated at being confined to bed due to food poisoning at a friend’s party.
Shweta’s friends summarised the session, and told her that they didn’t know what the upcoming sessions, though related to hardware, would be about. When the doctor requested them to leave, they took the opportunity to plan and talk about the most common hardware-controlling operation, ioctl(). Introducing ioctl() Input/Output Control (ioctl, in short) is a common operation, or system call, available in most driver categories.
It is a one-bill-fits-all kind of system call. The question is: how can all this be achieved by a single function prototype? However, from kernel 2.6.35, it changed to: Querying driver-internal variables. The Linux Kernel Module Programming Guide. Peter Jay SalzmanMichael BurianOri Pomerantz Copyright © 2001 Peter Jay Salzman 2007-05-18 ver 2.6.4 The Linux Kernel Module Programming Guide is a free book; you may reproduce and/or modify it under the terms of the Open Software License, version 1.1. You can obtain a copy of this license at This book is distributed in the hope it will be useful, but without any warranty, without even the implied warranty of merchantability or fitness for a particular purpose.
The author encourages wide distribution of this book for personal or commercial use, provided the above copyright notice remains intact and the method adheres to the provisions of the Open Software License. Derivative works and translations of this document must be placed under the Open Software License, and the original copyright notice must remain intact.