There are approximately a dozen filetypes  on a modern Unix or linux system. We are well acquainted with a few of these: especially regular files, directories, and symbolic links. There are two filetypes devoted to devices: character device files and block device files. The filetype appears as the first character in the output of a long listing. A block device is identified by the filetype b. A character device is identified by the filetype c. 

Device files are kept in the /dev directory. Although this is a only convention, any device file appearing outside of this protected directory should be suspect, and any device file that is not owned by root or has any permissions for any non-protected user is a serious security issue, as it allows direct access and/or modification of the filesystem by other users. There is a simple mechanism for disabling device files on a filesystem by filesystem basis that we will cover later.

The purpose of a device file is to attach a device to its driver in the kernel. To this end, there are only three pieces of information the device file conveys to the kernel:

• whether the device is a character or block device (determined by the type of device file used)
• which driver to use to handle the device (this is called the device's major number)
• to identify to the driver which specific device it is, since a driver is often responsible for many devices (this is called the device's minor number)

Besides the file type, this information is encoded in the device file's inode, by overloading the size field, which is meaningless when speaking of a device. Thus, when a long listing is done of a device file, the size field will appear as two numbers: the device major number and the device minor number.

$ ls -l /dev/hda1
brw-rw----  1 root disk 3, 1 Jan 21 09:15 /dev/hda1
$

The device file listed above is a block device. It's major number is 3 and its minor number is 1. It's name indicates that it is the first partition of the first hard disk, as we will see later. To this end, the device file for the second partition of this device should be similar:

$ ls -l /dev/hda2
brw-rw----  1 root disk 3, 2 Jan 21 09:15 /dev/hda2
$

As might be predicted, the driver (identified by the major number) is the same for these two devices, and the 'class member' (which device the driver is responsible for, as identified by the minor number), differs by one since the partition number (which is what the minor number indicates) differs by one. Note that the minor number of the first partition may not be one, but it should differ from the second partition by one.

Device files are created by the mknod command. Although this command is reserved for root, device files can be created anywhere. The only parameters required for mknod are the major and minor number, whether it is a block or character device, and the name to give the device file.

The major and minor device numbers kept in [the inode of] a device file are totally system-dependent. There is no easy way to predict what these numbers will be. However, they do follow a pattern, and it is possible to extrapolate them if you have available a similar device file. Very seldom today does the system administrator need to use mknod to create a device file by hand.

Traditionally, a Unix system had a huge number of device files created during the installation process. Some of these device files would eventually be used, but most corresponded to devices which were not present. The creation of these device files was usually handled by a program (or shell script) called makedev or MAKEDEV. The MAKEDEV program still exists on our systems. I am not sure if it is ever used, but it could be used by the administrator to create a persistent device file if need be. MAKEDEV uses the rules encoded in /etc/makedev.d to create the device files.

A minimal set of device files is created at system installation.  After that, the normal creation of device files on a modern linux system is an event-driven process. As near as I can figure, here is the short version of how it works. (This information is advanced, and is just added for depth. We are not studying these facilities in detail. In fact, the section on dbus has been removed from this class due to time constraints.)

• when a device is detected, either during kernel initialization or when a device (such as a usb device) is inserted, the kernel issues a uevent.
• the udev daemon responds to the uevent and consults its rules in /etc/udev/rules.d (and /lib/udev) to determine the device to create, modify or remove. The rules may include instructions on a "helper" program that should be run to configure the device. Once the device is created, it remains (even through system reboots) until it is removed by another uevent.
  
• the changes in devices are broadcast on the system bus (dbus) so that desktop applications can take appropriate action. This used to be the responsibility of hald, the hardware abstraction layer daemon, but this capability has been merged into udev. The udisks (formerly devicekit) API provides an interface specification for accessing this dynamic device data by applications.

Block or character

How the device accesses data is identified by whether it is a block  or a character device. Character devices access data as a character stream. An example of a character device would be a terminal. Very little buffering is done on character devices, and the characters must be output to the device in a strict order. Block devices transmit data in blocks. Data going to or coming from the device is transferred in blocks of some size. The system is free to optimize how these blocks are actually read and written: so long as they all get to their destination they need not be in the order they were transmitted. An example of a block device is a hard disk drive.

Device file names

There is no 'file' (i.e., no data blocks) assocated with a device file. It is simply a placeholder whose inode contains the three parameters device type, major number and minor number. Of course, the system does not care what the name of the device file is. For human eyes, however, a description of the device is encoded in the name of the device file. It is very important to realize that the name is meaningless. Recall one of the examples of a device file we saw earlier:

This is an example of a BSD-style device naming convention. The name consists of a few characters to indicate the device, and a few characters to indicate which device of that type we are speaking about. In this case, hd indicates 'hard disk', or, actually, IDE disk, a indicates 'the first disk' and 1 indicates 'the first partition'. Another common hard disk identifier is sd, which indicates a disk which is SCSI or which uses SCSI emulation. Other character sequences that indicate device type are tty,fd (floppy disk), dvd, cd, lp (line printer). 

As we indicated before, device files do not have to be located in /dev. Using the same system as the previous examples if we took one of the device files from /dev and placed it in another directory, you could certainly use it:

Question: which disk and partition does the above device file access?  (Answer this question before you proceed.) 

If you answered the third partition of the first hard disk, you are incorrect! The name of this device file has been changed. If you look at the numbers encoded in it and compare it to the previous examples, you will find that it accesses the second partition of the first disk.

This contrived example shows that it is very tempting to rely on the name of the device file. This is why you should never allow the use of device files where they can be manipulated by a normal user. Although it is illegal for a normal user to create a device file, it is not illegal for them to rename one, if it is in a directory to which they have permissions.

The names of device files on systems derived from System V are more complicated than those on BSD variants (which may be why linux chose to follow BSD conventions in this case). For example, the device file name for a partition on a hard disk on a System V system might be something like c0t4d2s1, where the number that follows c indicates the controller number, the number that follows t indicates the SCSI id number, the number that follows d indicates the disk number, and the number that follows s indicates the partition (slice) number.

Exercise: Log on to one of our classroom systems and find the device name for one of your hard disk's partitions. Then list (in long format) all the devices correponding to partitions on that disk. For example, if the device file listed in the output of the df command for your root partition is /dev/hda2, list all the device files in /dev for the device hda. How many do you see? Are there more than are being used? (again, look at the output of the df or mount commands). The major numbers should be the same. How do the minor numbers compare?

Copyright 2014 Greg Boyd - All Rights Reserved.