Chapter 6: Device Drivers
In addition to the task outlined above, the udev daemon also assumes some more responsibilities like
ensuring that device nodes for specific devices always have the same name irrespective of the device
topology. For instance, users usually desire to havethe same device node for USB sticks independent of
when and where they are plugged in. Refer to the manual pageudevd(5)for more information on how
the udev daemon handles such cases — this is a pure userspace problem and nothing the kernel needs
to be concerned about.6.2.3 Device Addressing Using Ioctls
Even though character and block devices generallyfit snugly in the structures of the filesystem and
therefore conform to theUnixphilosophy that ‘‘everything is a file,‘‘ some tasks are very difficult to
perform using only input and output commands. These involve checking device-specific functions and
properties that are not within the general file framework. A prime example is setting the configuration of
a device.If is, of course, possible to carry out such tasks by defining ‘‘magic‘‘ strings with special meanings and
using genericreadandwritefunctions. For example, an approach of this kind can be used with a floppy
disk drive to support software ejection. The device driver could monitor the data stream to the device
and eject the disk from the drive when it encounters the stringfloppy: eject. Special codes can likewise
be defined for other tasks.This method has one obvious disadvantage. What happens if a text file containing the above string is
written to floppy disk (the text may be part of an operating guide for the disk drive)? The driver would
eject the disk — to the annoyance of the user because thisisnotwhatiswanted.Naturally,itispossible
to prevent this situation by having a userspace application check that the string does not appear in the
text or by masking it if it does (an appropriate method would also have to be defined to do this too). This
whole process is not only a waste of time and resources but lacks elegance and sophistication.^4The kernel must therefore provide a way of supporting special device properties without having recourse
to normal Read and Write commands. One way of doing this is to introduce special system calls. How-
ever, this a deprecated practice among kernel developers and is therefore used only for a few very
popular devices. A more appropriate solution goes by the name ofIOCTL, which stands forinput output
control interfaceand is a general interface for configuring and modifying specific device characteristics.
There’s also a third alternative available: Sysfs, a file system that hierarchically represents all devices of
the system, and also provides means to set parameters for these devices. More information about this
mechanism is contained in Section 10.3. For now, I will stick to the slightly more old-fashioned, but still
valid IOCTL method.Ioctls are implemented by means of a special method that can be used to process files. This method
produces the desired results when applied to device files but has no effect when used with regular files.
Chapter 8 discusses how the implementation fits into the virtual filesystem schema. All we need to know
at this point is that each device driver is free to define an ioctl routine that enables control data to be
transferred separately from the actual input/output channel.How are ioctls employed from a user and programming point of view? The standard libraries pro-
vide theioctlfunction to direct an ioctl command to an opened file by means of a specific code. The(^4) For historical reasons, some drivers do employ this method. It is used widely with terminals to transfer control characters to modify
device properties such as text color, cursor position, and so on.