Miscellaneous Character Drivers
If you have tried to write your own misc driver but insmod returned unresolved symbol misc_register, you have a problem in your kernel configuration.
Originally, the misc driver was designed as a wrapper for all the “busmouse” drivers—the kernel drivers for every non-serial pointer device. The driver was only compiled if the current configuration included at least one such mouse driver. Just before version 2.0, the generality of the implementation was widely accepted, and the driver was renamed from “mouse” to “misc”. It is still true, however, that the driver is not available unless you chose to compile at least one of the misc devices as either a module or a native driver.
If you don't have any such devices installed on your system, you can still load your custom misc modules, provided you reply affirmatively, while configuring your kernel, to the question:
Support for user misc device modules (CONFIG_UMISC)
This option indicates that the misc driver is to be compiled even if no misc device has been selected, thus allowing run-time insertion of third-party modules. The file /proc/misc and support for dynamic minor numbers were implemented when this option was introduced, as there's little point in having custom modules unless the allocation of a minor number is safe.
Note that if your kernel is configured to load busmice only as modules, everything will work with the exception of /proc/misc. The /proc file is created only if miscdevice.c is directly linked in the kernel. CONFIG_UMISC takes care of this situation as well.
Every time a process interacts with a device driver, the implementation of the system call gives control to the correct driver by means of the file_operations structure. This structure is carried around by struct file: every open file descriptor is associated to one such structure, and file.f_op points to its own file_operations structure.
This setup is similar to object-oriented languages: every object (here, every file) declares how to act on itself, so that high-level code is independent of the actual file being accessed. The Linux kernel is full of object-oriented programming in its implementations, and several “operations” structures exist in it, one for each different “object” (inodes, memory regions, etc.).
Back to the misc driver. How does my_dev.fops participate in the game? At open time, the kernel allocates a new file structure to describe the object being opened, and initializes its operations structure according to what the file is. Sockets, FIFOs, disk files and devices get their own, different, operations. When a device is opened, its operations are looked up according to the major device number by referencing an array. The open method within the driver is then called. Any other system call that acts on a file will then use file.f_op without checking any other source of information. As a result, a driver can replace the value of file.f_op to tailor the behaviour of a struct file to some inner feature, even if that feature is at a finer grain than the major number, and thus is not visible from the kernel proper.
The open method of the misc driver is able to dispatch operations to the actual low-level driver by modifying file.f_op; the assigned value is the one in my_dev.f_op. After the operations have been overridden, the method calls file.f_op->open(), so that the low-level driver can perform its own initialization. Every other system call invoked on the file will use the new value of file.f_op, and the low-level driver keeps complete control over its device.
Since the discussion up to now has been much too philosophical, it's time to move to a working example. The kiss module (Keyboard Informative Status Signals) is a simple tool to play with the keyboard LEDs. It registers itself as a misc device using dynamic minor-number assignment and is controlled by writing textual commands to it. It accepts several one-byte commands, such as “N” and “n” (to turn the Num-Lock LED on and off), the digits from 0 to 7 (to display binary numbers in that range using the LEDs) and so on.
I don't think there's any need to include source code here, as the driver does little more than the misc_register code shown above. Most of the additional code deals with interpretation of the commands and actual lighting of the LEDs. The tar file with source code and a README file can be retrieved from ftp://ftp.linuxjournal.com/pub/lj/listings/issue51/2920.tgz.
As usual, the sample module that accompanies this article is pretty simple and is of little interest in the real world. This time, however, I think it can be of some interest. As a matter of fact, custom hardware in my computer includes three LEDs to monitor the number of running processes. In my opinion, this is useful information when you are wondering why the computer is not responding—a situation quite common whenever you write buggy drivers or drivers that print too many diagnostic messages.
Alessandro is still using Linux 2.0, because he's spending his spare time building his own misc devices with a soldering iron. He enjoys open source and open air, and reads e-mail as firstname.lastname@example.org.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- The Italian Army Switches to LibreOffice
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Linux Mint 18
- Oracle vs. Google: Round 2
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
- Devuan Beta Release
- Varnish Software's Varnish Massive Storage Engine
- Privacy and the New Math
- Ben Rady's Serverless Single Page Apps (The Pragmatic Programmers)
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide