I've been reading up on udev. In the "overview" section, Wikipedia states that "unlike traditional Unix systems, where the device nodes in the /dev directory have been a static set of files, the Linux udev device manager dynamically provides only the nodes for the devices actually present on a system".
What does it mean when it says "static set of files"? Does it mean that there are always /dev files but they don't always point to a real device?
I assume you're referring to this paragraph:
Unlike traditional Unix systems, where the device nodes in the /dev directory have been a static set of files, the Linux udev device manager dynamically provides only the nodes for the devices actually present on a system. Although devfs used to provide similar functionality, Greg Kroah-Hartman cited a number of reasons3 for preferring its implementation over devfs:
From the 1st sentence they're referring to other Unix systems where the devices in /dev are statically created and persisted from reboot to reboot. Previous versions of Linux (think the 2.4 version of the Kernel) used to work this way too, newer versions no longer behave in this manner. Other Unixes typically include a common set of device files when you install them, and only rarely is it necessary to manually create additional ones.
In 2.4 you could use the mknod command to manually to create any necessary device files. For example:
$ mknod ./dev/random b 12 5
NOTE: This is stating create the /dev/random file descriptor, as a block device with major device number of 12 and a minor device number of 5.
The OP asked the following follow-up question regarding the overall functionality of the /dev directory. Here's his question:
Can you add details on the technical method used to persist device files across reboots? how are they physically stored on disk? did they need special filesystem support?
In researching this I figured I'd start with the Linux From Scratch project to get a basic idea of how /dev is managed in newer versions of the Linux kernel. I know that in the past (think Kernel versions 2.4 and before) the /dev directory was a static set of files that literally took up space on the HDD, but with the advent of udev and sysfs this was no longer the case.
Traditionally, these special files were created at install time by the distribution, using the mknod command. In recent years, Linux systems began using udev to manage these /dev files at runtime. For example, udev will create nodes when devices are detected and delete them when devices are removed (including hotplug devices at runtime). This way, the /dev directory contains (for the most part) only entries for devices which actually exist on the system at the current time, as opposed to devices which could exist.
So gone are the days of having to worry about your device files under /dev. This directory is now completely managed by udev and sysfs from reboot to reboot.
udev & sysfs resources"device files" are a special type of file (in much the same way directories, symlinks, named pipes and unix domain sockets are special types of file). They do not store user data directly, instead they store a major and minor device number and a device type (char or block). Filesystems designed for unix-like systems will have support for storing device files.
When a "device file" is accessed either by an application or through a mount command the major and minor device number and the device type are retrived from the filesystem. Based on these numbers the kernel selects the driver and opens it.
Traditionally device files just existed in a directory on the root filesystem called /dev , usually created by a tool called "MAKEDEV" which reads configuration files and creates device nodes. This is reffered to as a static set up and was used for many years by pretty much every unix-like OS including linux. There are a few downsides to this approach.
linux's first attempt at solving this problem was called devfs (some other unix-like operating systems also have a filesystem called devfs but I don't know the details). This was a virtual filesystem where the kernel would provide device nodes. Afaict it was relatively stillborn, it pushed it's own nonstandard device naming scheme whether you liked it or not and didn't offer massive advantages over a static /dev
Later udev came along. This used a different model. A tmpfs was mounted on /dev and a userspace dameon managed the device nodes in it based on notifications from the kernel. https://lwn.net/Articles/65197/
More recently there has also been something called devtmpfs. This seems to be something of a compromise where the kernel creates a set of basic device nodes, but userspace can take over if more complex functionality is desired.
On the Altos 386 (i386/SCO SysV Unix) system an example of a static device that had to be created at kernel upgrade (or re install) was the plethora of /dev/mt entries to support SCSI HP Dat Tape units. The major number was for the tape driver on SCSI Bus and the minors were for the SCSI device number and features (raw, rewind no rewind come to mind). There were two SCSI busses and they could support multiple mixed tape units and mounted HD extension file systems on each bus.
The dev's were just entries in the root file system made with MAKEDDEV. For practical purposes they could be linked to more usable names so the rewind device on SCSI device 5 could be linked to /dev/st (SCSI tape to distinguish it from an inbuilt DC300 unit)
Later we had to do the same when we started using Slackware Linux and had to manually patching the .99b kernel to use 3Com 3C509b combo ethernet cards correctly. These had cat5, BNC and AUI connectors and the sport was getting the right interface up at boot time
