Miscellaneous Character Drivers

Alessandro tells us how to register a small device needing a single entry point with the misc driver.

Sometimes people need to write “small” device drivers, to support custom hacks—either hardware or software ones. To this end, as well as to host some real drivers, the Linux kernel exports an interface to allow modules to register their own small drivers. The misc driver was designed for this purpose. The code introduced here is meant to run with version 2.0 of the Linux kernel.

In UNIX, Linux and similar operating systems, every device is identified by two numbers: a “major” number and a “minor” number. These numbers can be seen by invoking ls -l /dev. Every device driver registers its major number with the kernel and is completely responsible for managing its minor numbers. Use of any device with that major number will fall on the same device driver, regardless of the minor number. As a result, every driver needs to register a major number, even if it only deals with a single device, like a pointing tool.

Since the kernel keeps a static table of device drivers, frivolous allocation of major numbers is rather wasteful of RAM. The Linux kernel, therefore, offers a simplified interface for simple drivers—those that will register a single entry point. Note that, in general, allocating the whole name space of a major number to every device is beneficial. This allows the handling of multiple terminals, multiple serial ports and several disk partitions without any overhead in the kernel proper: a single driver takes care of all of them, and uses the minor number to differentiate.

Major number 10 is officially assigned to the misc driver. Modules can register individual minor numbers with the misc driver and take care of a small device, needing only a single entry point.

Registering a Minor Number

The misc driver exports two functions for user modules to register and unregister their own minor number:

#include <linux/miscdevice.h>
int misc_register(struct miscdevice * misc);
int misc_deregister(struct miscdevice * misc);

Each user module can use the register function to create its own entry point for a minor number, and deregister to release resources at unload time.

The miscdevice.h file also declares struct miscdevice in the following way:

struct miscdevice {
        int minor;
        const char *name;
        struct file_operations *fops;
        struct miscdevice *next, *prev;
};

The five fields have the following meaning:

  • minor is the minor number being registered. Every misc device must feature a different minor number, because such a number is the only link between the file in /dev and the driver.

  • name is the name for this device, meant for human consumption: users will find the name in the /proc/misc file.

  • fops is a pointer to the file operations which must be used to act on the device. File operations have been described in a previous “Kernel Korner” in April 1996. (That article is available on the web at http://www.linuxjournal.com/issue24/kk24.html.) Anyway, the topic is refreshed later in this article.

  • next and prev are used to manage a circularly-linked list of registered drivers.

The code calling misc_register is expected to clear prev and next before invoking the function and to fill the first three fields with sensible values.

The real question with the misc device driver is “what is a sensible value for the minor field?” Assignment of minor numbers is performed in two ways: either you can use an “officially assigned” number, or you can resort to dynamic assignment. In the latter case, your driver asks for a free minor number, and the kernel returns one.

The typical code sequence for assigning a dynamic minor number is as follows:

static struct miscdevice my_dev;
int init_module(void)
{
    int retval;
    my_dev.minor = MISC_DYNAMIC_MINOR;
    my_dev.name = "my";
    my_dev.fops = &my_fops;
    retval = misc_register(&my_dev);
    if (retval) return retval;
    printk("my: got minor %i\n",my_dev.minor);
    return 0;
}

Needless to say, a real module will perform some other tasks within init_module. After successful registration, the new misc device will appear in /proc/misc. This informative file reports which misc drivers are available and their minor numbers. After loading my, the file will include the following line:

63 my
This shows that 63 is the minor number returned. If you want to create an entry point in /dev for your misc module, you can use a script like the one shown in Listing 1. The script takes care of creating the device node and giving it the desired permission and ownership.

You might choose to find an unused minor number and hardwire it in your driver. This would save invoking a script to load the module, but the practice is strongly discouraged. To keep the code compact, drivers/char/misc.c doesn't check for duplication of minor numbers. If the number you chose is later assigned to an official driver, you'll be in trouble when you try to access both your module and the official one.

If the same minor number is registered twice, only the first one will be accessible from user space. Although seemingly unfair, this can't be considered a kernel bug, as no data structure is corrupted. If you wish to register a safe minor number, you should use dynamic allocation.

The file Documentation/devices.txt in the kernel source tree lists all of the official device numbers, including all the minor numbers for the misc driver.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState