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
Earlier, in kernel 2.4, the automatic creation of device files was done by the kernel itself, by calling the appropriate APIs of
devfs. However, as the kernel evolved, kernel developers realised that device files were more related to user-space and hence, as a policy, that is where they ought to be dealt with, not at the kernel. Based on this idea, the kernel now only populates the appropriate device class and device information into the
/sys window, for the device under consideration. User-space then needs to interpret it and take appropriate action. In most Linux desktop systems, the
udev daemon picks up that information, and accordingly creates the device files.
udev can be further configured via its configuration files to tune the device file names, their permissions, their types, etc. So, as far as the driver is concerned, the appropriate
/sys entries need to be populated using the Linux device model APIs declared in
<linux/device.h>. The rest should be handled by
udev. The device class is created as follows:
Then, the device info (
<major, minor>) under this class is populated by:
Here, the first is
dev_t with the corresponding
<major, minor>. The corresponding complementary or the inverse calls, which should be called in chronologically reverse order, are as follows:
Refer to Figure 1 for the
/sys entries created using
chardrv as the
<device class name>and
mynull as the
<device name format>. That also shows the device file, created by
udev, based on the
<major>:<minor> entry in the
Figure 1: Automatic device file creation
In case of multiple minors, the
device_destroy() APIs may be put in the for loop, and the
<device name format> string could be useful. For example, the
device_create() call in a for loop indexed by
i could be as follows:
Whatever system calls (or, more commonly, file operations) we talk of on a regular file, are applicable to device files as well. That’s what we say: a file is a file, and in Linux, almost everything is a file from the user-space perspective. The difference lies in the kernel space, where the virtual file system (VFS) decodes the file type and transfers the file operations to the appropriate channel, like a filesystem module in case of a regular file or directory, and the corresponding device driver in case of a device file. Our discussion focuses on the second case.
Now, for VFS to pass the device file operations onto the driver, it should have been informed about it. And yes, that is what is called registering the file operations by the driver with the VFS. This involves two steps. (The parenthesised code refers to the “null driver” code below.)
First, let’s fill in a file operations structure (
struct file_operations pugs_fops) with the desired file operations (
my_write, …) and initialise the character device structure (
struct cdev c_dev) with that, using
Then, hand this structure to the VFS using the call
cdev_add() are declared in
<linux/cdev.h>. Obviously, the actual file operations (
my_write) also had to be coded.
So, to start with, let’s keep them as simple as possible — let’s say, as easy as the “null driver”.
The null driver
Following these steps, Shweta put the pieces together, attempting her first character device driver. Let’s see what the outcome was. Here’s the complete code —
Shweta repeated the usual build process, with some new test steps, as follows:
- Build the driver (
.kofile) by running
- Load the driver using
- List the loaded modules using
- List the major number allocated, using
- “null driver”-specific experiments (refer to Figure 2 for details).
- Unload the driver using
Figure 2: ‘null driver’ experiments
Shweta was certainly happy; all on her own, she’d got a character driver written, which works the same as the standard
/dev/null device file. To understand what this means, check the
<major, minor> tuple for
/dev/null, and similarly, also try out the
cat commands with it.
However, one thing began to bother Shweta. She had got her own calls (
my_write) in her driver, but wondered why they worked so unusually, unlike any regular file system calls. What was unusual? Whatever was written, she got nothing when reading — unusual, at least from the regular file operations’ perspective. How would she crack this problem? Watch out for the next article.