Hubbry Logo
Device fileDevice fileMain
Open search
Device file
Community hub
Device file
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Device file
Device file
Device file
View on Wikipedia
from Wikipedia

In Unix-like operating systems, a device file, device node, or special file is an interface to a device driver that appears in a file system as if it were an ordinary file. There are also special files in DOS, OS/2, and Windows. These special files allow an application program to interact with a device by using its device driver via standard input/output system calls. Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions.

Overview

[edit]

Device files usually provide simple interfaces to standard devices (such as printers and serial ports), but can also be used to access specific unique resources on those devices, such as disk partitions. Additionally, device files are useful for accessing system resources that have no connection with any actual device, such as data sinks and random number generators.

There are two general kinds of device files in Unix-like operating systems, known as character special files and block special files. The difference between them lies in how much data is read and written by the operating system and hardware. These together can be called device special files in contrast to named pipes, which are not connected to a device but are not ordinary files either.

MS-DOS borrowed the concept of special files from Unix but renamed them devices.[1] Because early versions of MS-DOS did not support a directory hierarchy, devices were distinguished from regular files by making their names reserved words that cannot be used as folder or file names; for example: the word CON is a reserved word. These were chosen for a degree of compatibility with CP/M and are still present in modern Windows for backwards compatibility. Names are not case-sensitive, so "con", "Con", and "CON" are all invalid names.

In Windows XP, entering "Con" into the Run command returns the error message, "This file does not have a program associated with it for performing this action. Create an association in the Folder Options control panel." Attempting to rename any file or folder using a reserved name silently reverts the file or folder to its previous name (or "New Folder", "New Text Document", etc.), with no notification or error message.[2] In Windows Vista and later, attempting to use a reserved name for a file or folder brings up an error message saying, "The specified device name is invalid."[2]

In some Unix-like systems, most device files are managed as part of a virtual file system traditionally mounted at /dev, possibly associated with a controlling daemon, which monitors hardware addition and removal at run time, making corresponding changes to the device file system if that's not automatically done by the kernel, and possibly invoking scripts in system or user space to handle special device needs. The FreeBSD, DragonFly BSD and Darwin have a dedicated file system devfs; device nodes are managed automatically by this file system, in kernel space. Linux used to have a similar devfs implementation, but it was abandoned later, and then removed since version 2.6.17;[3] Linux now primarily uses a user space implementation known as udev, but there are many variants.

In Unix systems which support chroot process isolation, such as Solaris Containers, typically each chroot environment needs its own /dev; these mount points will be visible on the host OS at various nodes in the global file system tree. By restricting the device nodes populated into chroot instances of /dev, hardware isolation can be enforced by the chroot environment (a program can not meddle with hardware that it can neither see nor name—an even stronger form of access control than Unix file system permissions).

MS-DOS managed hardware device contention (see terminate-and-stay-resident program) by making each device file exclusive open. An application attempting to access a device already in use would discover itself unable to open the device file node. A variety of device driver semantics are implemented in Unix and Linux concerning concurrent access.[4]

Unix and Unix-like systems

[edit]
A simplified structure of the Linux kernel. File systems are implemented as part of the I/O subsystem.

Device nodes correspond to resources that an operating system's kernel has already allocated. Unix identifies those resources by a major number and a minor number,[5] both stored as part of the structure of a node. The assignment of these numbers occurs uniquely in different operating systems and on different computer platforms. Generally, the major number identifies the device driver and the minor number identifies a particular device (possibly out of many) that the driver controls:[6] in this case, the system may pass the minor number to a driver. However, in the presence of dynamic number allocation, this may not be the case (e.g. on FreeBSD 5 and up).

As with other special file types, the computer system accesses device nodes using standard system calls and treats them like regular computer files. Two standard types of device files exist; unfortunately their names are rather counter-intuitive for historical reasons, and explanations of the difference between the two are often incorrect as a result.

Character devices

[edit]

Character special files or character devices provide unbuffered, direct access to the hardware device. They do not necessarily allow programs to read or write single characters at a time; that is up to the device in question. The character device for a hard disk, for example, will normally require that all reads and writes be aligned to block boundaries and most certainly will not allow reading a single byte.

Character devices are sometimes known as raw devices to avoid the confusion surrounding the fact that a character device for a piece of block-based hardware will typically require programs to read and write aligned blocks.

Block devices

[edit]

Block special files or block devices provide buffered access to hardware devices, and provide some abstraction from their specifics.[7] Unlike character devices, block devices will always allow the programmer to read or write a block of any size (including single characters/bytes) and any alignment. The downside is that because block devices are buffered, the programmer does not know how long it will take before written data is passed from the kernel's buffers to the actual device, or indeed in what order two separate writes will arrive at the physical device. Additionally, if the same hardware exposes both character and block devices, there is a risk of data corruption due to clients using the character device being unaware of changes made in the buffers of the block device.

Most systems create both block and character devices to represent hardware like hard disks. FreeBSD and Linux notably do not; the former has removed support for block devices,[8] while the latter creates only block devices. To get the effect of a character device from a block device on Linux, one must open the device with the Linux-specific O_DIRECT flag.

Pseudo-devices

[edit]

Device nodes on Unix-like systems do not necessarily have to correspond to physical devices. Nodes that lack this correspondence are called pseudo-devices. They provide various functions handled by the operating system. Some of the most commonly used (character-based) pseudo-devices include:

  • /dev/null – accepts and discards all input written to it; provides an end-of-file indication when read from.
  • /dev/zero – accepts and discards all input written to it; produces a continuous stream of null characters (zero-value bytes) as output when read from.
  • /dev/full – produces a continuous stream of null characters (zero-value bytes) as output when read from, and generates an ENOSPC ("disk full") error when attempting to write to it.
  • /dev/random – produces bytes generated by the kernel's cryptographically secure pseudorandom number generator. Its exact behavior varies by implementation, and sometimes variants such as /dev/urandom or /dev/arandom are also provided.
  • /dev/stdin, /dev/stdout, /dev/stderr – access the process's standard streams.
  • /dev/fd/n – accesses the process's file descriptor n.

Additionally, BSD-specific pseudo-devices with an ioctl interface may also include:

Node creation

[edit]

Nodes are created by the mknod system call. The command-line program for creating nodes is also called mknod. Nodes can be moved or deleted by the usual filesystem system calls (rename, unlink) and commands (mv, rm).

Some Unix versions include a script named makedev or MAKEDEV to create all necessary devices in the directory /dev. It only makes sense on systems whose devices are statically assigned major numbers (e.g., by means of hardcoding it in their kernel module).

Some other Unix systems such as FreeBSD use kernel-based device node management via devfs only and do not support manual node creation. mknod(2) system call and mknod(8) command exist to keep compatibility with POSIX, but manually created device nodes outside devfs will not function at all.[10]

Naming conventions

[edit]

The following prefixes are used for the names of some devices in the /dev hierarchy, to identify the type of device:

Some additional prefixes have come into common use in some operating systems:

  • fb: frame buffer
  • fd: (platform) floppy disks, though this same abbreviation is also commonly used to refer to file descriptor
  • hd: ("classic") IDE driver (previously used for ATA hard disk drive, ATAPI optical disc drives, etc.)
    • hda: the primary device on the first ATA channel (usually identified by major number 3 and minor number 0)
    • hdb: the secondary device on the first ATA channel
    • hdc: the primary device on the second ATA channel
    • hdd: the secondary device on the second ATA channel
  • parport, pp: parallel ports
  • mem: Main memory (character device)
  • nbd: Network block device: Abstraction that represents block devices that are mounted through the network (or from images using qemu-nbd)
  • NVMe driver:
    • nvme0: first registered device's device controller (character device)
    • nvme0n1: first registered device's first namespace (block device)
    • nvme0n1p1: first registered device's first namespace's first partition (block device)
  • MMC driver:
    • mmcblk: storage driver for MMC media (SD cards, eMMC chips on laptops, etc.)
      • mmcblk0: first registered device
      • mmcblk0p1: first registered device's first partition
  • SCSI driver, also used by libATA (modern PATA/SATA driver), USB, IEEE 1394, etc.:
    • sd: mass-storage driver (block device)
      • sda: first registered device
      • sdb, sdc, etc.: second, third, etc. registered devices
    • ses: Enclosure driver
    • sg: generic SCSI layer
    • sr: "ROM" driver (data-oriented optical disc drives; scd is just a secondary alias)
    • st: magnetic tape driver
  • tty: terminals
    • ttyS: (platform) serial port driver
    • ttyUSB: USB serial converters, modems, etc.

The canonical list of the prefixes used in Linux can be found in the Linux Device List, the official registry of allocated device numbers and /dev directory nodes for the Linux operating system.[11]

For most devices, this prefix is followed by a number uniquely identifying the particular device. For hard drives, a letter is used to identify devices and is followed by a number to identify partitions. Thus a file system may "know" an area on a disk as /dev/sda3, for example, or "see" a networked terminal session as associated with /dev/pts/14.

On disks using the typical PC master boot record, the device numbers of primary and the optional extended partition are numbered 1 through 4, while the indexes of any logical partitions are 5 and onwards, regardless of the layout of the former partitions (their parent extended partition does not need to be the fourth partition on the disk, nor do all four primary partitions have to exist).

Device names are usually not portable between different Unix-like system variants, for example, on some BSD systems, the IDE devices are named /dev/wd0, /dev/wd1, etc.

devfs

[edit]

devfs is a specific implementation of a device file system on Unix-like operating systems, used for presenting device files. The underlying mechanism of implementation may vary, depending on the OS.

Maintaining these special files on a physically-implemented file system such as a hard drive is inconvenient, and as it needs kernel assistance anyway, the idea arose of a special-purpose logical file system that is not physically stored.

Defining when devices are ready to appear is not trivial. The devfs approach is for the device driver to request creation and deletion of devfs entries related to the devices it enables and disables.

PC DOS, TOS, OS/2, and Windows

[edit]

A device file is a reserved keyword used in PC DOS, TOS, OS/2, and Windows systems to allow access to certain ports and devices.

MS-DOS borrowed the concept of special files from Unix but renamed them devices.[1] Because early versions of MS-DOS did not support a directory hierarchy, devices were distinguished from regular files by making their names reserved words. This means that certain file names were reserved for devices, and should not be used to name new files or directories.[12] The reserved names themselves were chosen to be compatible with "special files" handling of PIP command in CP/M. There were two kinds of devices in DOS: Block Devices (used for disk drives) and Character Devices (generally all other devices, including COM and PRN devices).[13]

DOS uses device files for accessing printers and ports. Most versions of Windows also contain this support, which can cause confusion when trying to make files and folders of certain names, as they cannot have these names.[14] Versions 2.x of MS-DOS provide the AVAILDEV CONFIG.SYS parameter that, if set to FALSE, makes these special names only active if prefixed with \DEV\, thus allowing ordinary files to be created with these names.[15]

GEMDOS, the DOS-like part of Atari TOS, supported similar device names to DOS, but unlike DOS it required a trailing ":" character (on DOS, this is optional) to identify them as devices as opposed to normal filenames (thus "CON:" would work on both DOS and TOS, but "CON" would name an ordinary file on TOS but the console device on DOS). In MiNT and MagiC, a special UNIX-like unified filesystem view accessed via the "U:" drive letter also placed device files in "U:\DEV".

Device keyword[14] Use as input Use as output
CON Receives typed data until ^Z (Ctrl-Z) is pressed. Prints data to the console.
PRN[16] — Prints text to the printer, usually redirected to LPT1 or LST. Sometimes reconfigurable to other devices.[17][18][19]
AUX (not in OS/2[16]) Reads data from an auxiliary device, usually a serial device like COM1. Sometimes reconfigurable to other devices.[17][18][19] Sends data to an auxiliary device, usually a serial device like COM1. Sometimes reconfigurable to other devices.[17][18][19]
NUL Returns null or no data. Discards received data.
CLOCK$ (still named CLOCK in some versions of MS-DOS 2.11[20][17][18]) — —
KEYBD$ (only in multitasking MS-DOS) ? ?
KBD$ (only in OS/2[16]) ? ?
SCREEN$ (only in multitasking MS-DOS and OS/2[16]) ? ?
POINTER$ (only in OS/2[16]) ? ?
MOUSE$ (only in OS/2[16]) ? ?
$IDLE$ (only in DR-DOS (since 5.0) and Multiuser DOS (since Concurrent DOS 386) families) — —
CONFIG$ (only in MS-DOS 7.0 and higher) — —
LST (only in 86-DOS and DOS 1.x, also in Hewlett-Packard's MS-DOS 2.11 for the HP Portable Plus[17][18]) Returns no data. Sends data to the line printer. (LPT2 for Hewlett-Packard's MS-DOS 2.11[17][18])
PLT (only in Hewlett-Packard's MS-DOS 2.11 for the HP Portable Plus[17][18]) Returns no data. Sends data to the assigned plotter. The attached plotter device is reconfigurable.[17][18]
LPT1, LPT2, LPT3, and sometimes LPT4 (in DR-DOS 7.02 and higher and some versions of Multiuser DOS) — Sends data to the selected parallel port.
COM1, COM2, COM3, COM4 Reads data from the selected serial port. Sends data to the selected serial port.
82164A (only in Hewlett-Packard's MS-DOS 2.11 for the HP Portable Plus[17][18]) Redirects to COM2. Redirects to COM2.

Using shell redirection and pipes, data can be sent to or received from a device. For example, typing the following will send the file c:\data.txt to the printer: 

TYPE c:\data.txt > PRN

PIPE, MAILSLOT, and MUP are other standard Windows devices.[21]

IOCS

[edit]

The 8-bit operating system of Sharp pocket computers like the PC-E500, PC-E500S etc. consists of a BASIC interpreter, a DOS 2-like File Control System (FCS) implementing a rudimentary 12-bit FAT-like filesystem, and a BIOS-like Input/Output Control System (IOCS) implementing a number of standard character and block device drivers as well as special file devices including STDO:/SCRN: (display), STDI:/KYBD: (keyboard), COM: (serial I/O), STDL:/PRN: (printer), CAS: (cassette tape), E:/F:/G: (memory file), S1:/S2:/S3: (memory card), X:/Y: (floppy), SYSTM: (system), and NIL: (function).[22]

Implementations

[edit]
Operating System Filesystem or managing software Standard mount point Author Notes
Linux 2.3.46pre5–2.6.17 devfs[23] and devfsd /dev Richard Gooch Implemented fully in the kernel, with optional daemon devfsd to handle device node events in user space.[24] Obsolete – users are encouraged to migrate to udev and/or devtmpfs.
Linux 2.5– udev on any fs, but usually tmpfs /dev Greg Kroah-Hartman, Kay Sievers and Dan Stekloff Implemented largely in user space, device information is gathered from sysfs. Device files can be stored on a conventional general-purpose file system, or in a memory file system (tmpfs).
Linux 2.6.32– devtmpfs with or without udev /dev Kay Sievers, Jan Blunck, Greg Kroah-Hartman A hybrid kernel/userspace approach of a device filesystem to provide nodes before udev runs for the first time[25]
Solaris devfs[26] /devices Sun Microsystems Introduced with dynamic loaded drivers in Solaris-2.1
FreeBSD 2.0– devfs /dev Poul-Henning Kamp Implemented fully in the kernel.
DragonFly BSD 2.3.2– devfs /dev Alex Hornung Implemented fully in the kernel.
macOS devfs /dev Apple Inc. Implemented fully in the kernel.
HP-UX B.11.31 devfs /dev HP Implemented fully in the kernel.
Plan 9 # Bell Labs Implemented in the kernel.
RISC OS DeviceFS Devices: Acorn Computers DeviceFS was started in 1991[27] and first appeared in RISC OS 3. It manages several device like special files, most commonly: Parallel, Serial, FastParallel, and USB. The SystemDevices module implements the pseudo devices such as: Vdu, Kbd, Null and Printer.
MS-DOS, PC DOS, DR-DOS FAT \DEV (and /DEV) various As implemented in the kernel, character devices appear in the virtual \DEV directory and any disk directory. Under MS-DOS/PC DOS 2.x, the CONFIG.SYS AVAILDEV=FALSE directive can be used to force devices to exist only in \DEV.
MagiC, MiNT, MultiTOS U:\DEV[28][29] Application Systems Heidelberg, Eric R. Smith, Atari Corp. The special U: drive contains a virtual DEV directory, inside which one can find device files.
Windows 9x \\devices\ Microsoft
Windows NT \Device Microsoft The \Device directory is a part of Windows NT object namespace.
Windows NT Win32 Subsystem \\.\ Microsoft The \\.\ prefix makes supporting APIs access the Win32 device namespace instead of the Win32 file namespace. The Win32 device names are symbolic links to device names under Windows NT \Device directory.

See also

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Device file

View on Grokipedia
from Grokipedia
In Unix-like operating systems, a device file, also known as a special file or device node, is a type of file that acts as an interface for the kernel to communicate with hardware devices, device resources, or pseudo-devices, allowing user programs to access them through standard file operations such as reading and writing. These files are stored in the /dev directory and are distinguished from regular files by their special nature, where operations on the file are translated by the kernel into device-specific actions via associated device drivers. Each device file is uniquely identified by a pair of integers—the major number, which corresponds to the device driver handling a class of devices, and the minor number, which specifies the particular instance of the device. Device files are primarily divided into two categories: character special files and block special files, with the distinction based on how is accessed and processed by the kernel. Character devices (denoted by 'c' in file listings) support sequential, byte-stream access without built-in buffering, making them suitable for devices like keyboards, mice, terminals, and serial ports that handle one byte at a time. In contrast, block devices (denoted by 'b') enable to in fixed-size blocks—typically 512 bytes or larger—facilitating efficient operations for storage media such as hard disks, SSDs, and optical drives, where the kernel manages buffering to optimize . A third category, pseudo-devices, represents virtual or software-emulated devices without physical hardware, such as /dev/null (a sink that discards input) or /dev/random (a source of non-deterministic random bytes for cryptographic purposes). In traditional Unix systems, device files were statically created and maintained, but modern Linux distributions use dynamic management tools like udev to populate and update the /dev directory in real-time based on kernel events. When hardware is added or removed, the kernel sends uevents via a netlink socket to udev, which applies rules from configuration files to create, name, or remove device nodes and symbolic links accordingly, ensuring the file system reflects the current hardware state without requiring reboots. This approach supports persistent naming conventions, such as linking devices by UUID or hardware path in subdirectories like /dev/disk/by-uuid, enhancing reliability in environments with hot-pluggable hardware. Device files embody the Unix philosophy of treating everything as a file, simplifying user and application interactions with diverse hardware through a uniform interface.

Overview

Definition and Purpose

In Unix-like operating systems, a device file, also known as a special file or device node, is a type of file that provides an interface for user-space programs to interact with hardware devices, peripheral resources, or virtual (pseudo) devices through the kernel. These files enable standard file input/output operations—such as opening, reading, writing, and closing—to be used for device control, abstracting complex hardware interactions behind a simple, consistent managed by device drivers. Unlike regular files, which store persistent data in filesystem blocks, device files do not allocate or hold data; they act solely as entry points or handles that route system calls to the appropriate kernel modules without maintaining any file content or size. This design supports the of treating diverse system resources uniformly as files, allowing a single set of tools and system calls to manage both data storage and device operations seamlessly. The core mechanics of device files rely on two identifiers: a major number, which specifies the device driver or type responsible for handling requests (e.g., identifying IDE disk controllers), and a minor number, which distinguishes individual instances or subunits of that device (e.g., specific partitions). These numbers are embedded in the file's inode and used by the kernel's (VFS) to dispatch operations correctly. Device files are categorized broadly into character devices for byte-stream access and block devices for buffered block transfers, though their primary role remains enabling abstracted hardware communication.

Historical Context

Device files were invented in the early 1970s by and at as a core component of the Unix operating system, designed to simplify input/output (I/O) operations by treating devices uniformly as files. This approach allowed devices to be accessed using the same read and write system calls as ordinary files, eliminating the need for specialized I/O instructions and enhancing system modularity and protection mechanisms. The concept drew influence from the operating system, particularly its I/O system calls, which Unix adapted to create a more streamlined file-based interface for devices. Device files first appeared in early Unix implementations on the and PDP-11 computers starting around , with their structure and usage well-established by the time of the influential 1974 paper describing the Unix system. By , released in 1979, device files were a standard feature, residing in the /dev directory and supporting both character and block device types through numbers for driver identification. The evolution of device files continued through (BSD) variants and culminated in formal standardization via the IEEE 1003.1 specification in 1988, which codified the uniform treatment of devices as special files, including character special files for stream-oriented devices and block special files for buffered access. This standard defined portable interfaces for device I/O, such as open(), read(), and write(), along with terminal-specific controls, ensuring consistency across systems while abstracting hardware details. Key milestones in the 1990s included the introduction of devfs in 2.0 in 1994, which automated device node creation within the kernel to address limitations of static /dev populations in growing hardware environments. In , the shift toward dynamic device management began in the late 1990s with the development of devfs, initiated in 1998 and integrated into the 2.4 kernel series in 2001, enabling runtime population of /dev based on detected hardware.

Device Files in Unix-like Systems

Character Devices

Character device files in Unix-like operating systems provide an interface for stream-oriented hardware devices that transfer data sequentially, one byte at a time, without support for random access or internal buffering. These devices include input sources like keyboards and mice, as well as output sinks such as serial ports and printers, allowing user-space applications to interact with hardware through standard file system operations. The sequential nature ensures that data flows in a continuous stream, making character devices suitable for real-time or line-buffered interactions where positioning within the data is not required. Each character device file is identified by a pair of numbers: the major number, which specifies the kernel responsible for handling the device, and the minor number, which distinguishes between multiple instances or sub-devices managed by the same . For example, terminal devices under /dev/tty use major number 4, with minor numbers differentiating controlling terminals (e.g., /dev/tty0) from virtual consoles. This numbering scheme enables the kernel to route I/O requests to the appropriate code efficiently during system calls. Common examples of character device files include /dev/null, which discards all data written to it and returns on reads (major 1, minor 3); /dev/zero, which generates an endless supply of null bytes (0x00) upon reading while ignoring writes (major 1, minor 5); and /dev/random, a source of high-quality pseudorandom bytes derived from system entropy that may block if insufficient randomness is available (major 1, minor 8). These special files demonstrate the versatility of character devices for utility purposes beyond direct hardware mapping. Access to character devices occurs through POSIX-compliant system calls such as open(), read(), write(), and close(), declared in <unistd.h>, which translate to kernel-level invocations without seek functionality for data positioning. In the Linux , drivers for these devices are typically implemented as loadable modules that define a file_operations structure—an array of function pointers for handling operations like .open, .read, .write, and .—registered via mechanisms such as alloc_chrdev_region() and cdev_add(). This structure allows the kernel's (VFS) layer to dispatch requests to the driver's callbacks, ensuring seamless integration between user-space I/O and hardware-specific logic. Unlike block devices, which enable to fixed-size units, character devices prioritize unbuffered, byte-stream for latency-sensitive applications.

Block Devices

Block device files in systems represent hardware or virtual devices that support to data organized in fixed-size blocks, typically 512 bytes or 4 KB in size, such as hard disk drives and USB devices. These files enable the operating system to interact with storage media through buffered I/O operations, distinguishing them from character devices by allowing non-sequential data retrieval and modification. The kernel implements buffering for block devices via the , a memory-based structure that temporarily holds data pages read from or to be written to the device, thereby enhancing efficiency by minimizing direct hardware interactions and enabling read-ahead and write-behind optimizations. This mechanism integrates with the subsystem, treating block I/O as part of to batch requests and reduce latency. Common examples include /dev/sda for the first disk (major number 8, minor number 0) and /dev/loop0 for the first device that maps a file to a virtual block device (major number 7, minor number 0). Input/output operations on block device files are seekable, permitting the use of the lseek() to reposition the file offset anywhere within the device for , in contrast to the sequential streams typical of character devices. Device-specific controls, such as querying partition sizes or , are handled via ioctl() calls, with the kernel's block layer responsible for queuing, merging, and dispatching requests to the underlying driver for optimal throughput. Partitioning is encoded in the device file's minor number, where the base device (e.g., /dev/sda, minor 0) represents the entire disk, and partitions append sequential offsets (e.g., /dev/sda1, minor 1 for the first partition), supporting up to 15 partitions per or disk in the kernel's naming scheme (with up to 4 primary partitions in traditional MBR layouts).

Special and Pseudo Devices

Special and pseudo devices in systems, particularly , are character device files that do not directly map to physical hardware but instead simulate behaviors, provide virtual interfaces, or expose kernel services for management and application needs. These files operate under the same numbering scheme as standard character devices, allowing the kernel to route I/O operations to appropriate handlers without hardware involvement. Special devices include utilities like /dev/full, which simulates a full storage device by failing all write operations with an ENOSPC error, useful for testing application responses to disk-full conditions; it has major number 1 and minor number 7. Another example is /dev/urandom, a non-blocking source of pseudorandom numbers generated from kernel entropy pools, providing cryptographically secure output for applications requiring continuous random data without waiting for entropy depletion. Pseudo-devices encompass virtual interfaces such as pseudoterminals (PTYs), which emulate terminal behavior for es like remote shells. The /dev/ptmx file serves as the master pseudoterminal multiplexer, enabling dynamic allocation of PTY pairs upon opening; a obtains a master , and a corresponding slave appears in /dev/pts, facilitating applications like SSH for secure terminal sessions over networks. Memory-based special devices allow controlled access to system resources: /dev/mem provides a character interface to the physical RAM, permitting examination or modification of contents, though its use is highly restricted to prevent kernel corruption. Similarly, /dev/ports offers access to I/O , mimicking direct hardware interactions for low-level system programming, typically created with major number 1 and minor number 4. Kernel interfaces like /dev/kmsg enable userspace interaction with the kernel's logging ring buffer, allowing reads of printk messages in a structured format and writes to inject log entries, which supports tools for monitoring system events without relying on legacy /proc/kmsg. Security considerations are paramount for these devices due to their potential for system compromise; for instance, /dev/mem access is limited to the superuser (requiring CAP_SYS_RAWIO privilege) since Linux 2.6.12 to mitigate risks from unauthorized memory manipulation. Permissions on files like /dev/ports and /dev/ptmx are similarly restricted, often to root or specific groups, ensuring only privileged processes can exploit their capabilities.

Device Node Creation and Management

In systems, device nodes in the /dev directory are traditionally created statically using the mknod command, which allows administrators to manually specify the type, major number, and minor number for a device file. The command syntax is mknod <pathname> <mode> <major> <minor>, where <mode> indicates the device type—c for character devices or b for block devices—and the major and minor numbers identify the kernel driver and device instance, respectively. For example, the is created with mknod /dev/null c 1 3, assigning it to the character device driver with major number 1 and minor number 3. Early Unix systems relied on manual management of the /dev directory through scripts like MAKEDEV, which automated the creation of multiple device nodes based on predefined configurations. Executed from within /dev, such as ./MAKEDEV std for standard devices or ./MAKEDEV ttyS0 for a specific , the script uses mknod internally to populate the directory with nodes for common hardware like consoles, RAM disks, and storage devices. In these setups, administrators would run MAKEDEV during system installation or after kernel updates to ensure all necessary nodes were present, often editing the script to customize user, group, and permission settings. Device nodes created via mknod or MAKEDEV default to permissions of 0666 (read/write for owner, group, and others), but these are typically adjusted using chmod and chown to enforce security, with ownership set to root:root and permissions like crw-rw-rw- (666 in octal) for widely accessible devices such as /dev/null. For instance, after creation, chmod 666 /dev/null ensures broad readability and writability without execute privileges, while chown root:root /dev/null assigns system-level control. These settings prevent unauthorized access while allowing essential operations, and MAKEDEV scripts often apply them automatically for predefined devices. In static /dev configurations, hotplug events—such as device insertion—are handled by kernel-generated uevents that notify user-space scripts, which then invoke mknod or similar to create corresponding nodes on demand. The kernel emits these uevents via sockets when hardware changes occur, triggering hotplug handlers to probe for device details and populate /dev accordingly, maintaining compatibility with static setups. Cleanup in static setups involves manual removal of unused nodes using rm, as these files persist across reboots unless explicitly deleted, unlike temporary mounts where nodes may be removed upon unmounting. For example, after detaching a loop device, rm /dev/loop0 clears the entry, but in persistent static directories, administrators must monitor and prune obsolete nodes to avoid clutter or conflicts. Device nodes are identified by their major and minor numbers, which remain consistent for reuse upon recreation.

Naming Conventions and Filesystems

In systems, device file names follow conventions established by the and user-space tools, rather than strict mandates, which only require the presence of a /dev directory for device nodes without specifying naming patterns. For instance, and disk devices are typically named /dev/sd followed by a lowercase letter (e.g., /dev/sda for the first disk), with numeric suffixes for partitions (e.g., /dev/sda1), reflecting the order of detection by the kernel's block device layer. Similarly, terminal devices use prefixes like /dev/tty for virtual terminals (e.g., /dev/tty1) or /dev/ttyS for serial ports (e.g., /dev/ttyS0), while USB serial devices appear as /dev/ttyUSB followed by a number based on enumeration order. These patterns ensure predictable access for applications, though the exact assignment can vary by hardware configuration and boot sequence. For NVMe storage devices, the differs, using /dev/nvme followed by the controller number, , and partition (e.g., /dev/nvme0n1 for the first namespace on the first controller, and /dev/nvme0n1p1 for its first partition). The input subsystem introduces subdirectory structures for finer , with USB and other input devices (such as keyboards and mice) exposed under /dev/input/, where raw event interfaces are named /dev/input/event followed by a sequential number (e.g., /dev/input/event0). To enhance usability, creates symbolic links in subdirectories like /dev/input/by-id/ or /dev/input/by-path/, using attributes such as vendor IDs or physical paths for more stable references across reboots. provides no prescriptive guidelines for these names, leaving to implementation-specific mechanisms like udev rules, which define consistency without formal enforcement. Historically, the /dev directory was a static component of the root filesystem, populated with predefined device nodes via tools like mknod during system installation, limiting dynamism in early setups. In modern distributions, /dev is mounted as devtmpfs, a kernel-managed instance of the filesystem that resides in RAM and automatically populates device nodes upon driver registration, enabling efficient, on-demand creation without persistent storage overhead. This shift supports hotplugging and reduces boot time, with further refining the population by applying rules for permissions and additional symlinks. Cross-distribution consistency in naming is achieved through (the current implementation of ), which uses standardized rulesets to generate predictable names based on device attributes like serial numbers or bus locations, mitigating issues from varying hardware detection orders. For example, rules in /lib//rules.d/ ensure that storage devices receive stable identifiers in /dev/disk/by-uuid/ or similar, promoting portability across variants while adhering to the kernel's core conventions.

Device Files in Other Operating Systems

DOS, Windows, and OS/2

In DOS, device drivers are loaded during system initialization via DEVICE= statements in the file, which specify the drivers responsible for managing hardware such as disks, printers, and serial ports. Unlike systems, DOS does not represent devices as files in the filesystem; instead, it uses reserved device names like CON for the console, PRN for the printer, and AUX for the auxiliary port, which are handled directly by the DOS kernel without corresponding file entries. These names allow programs to redirect streams to devices transparently, but they cannot be used as filenames due to their special status. Windows, particularly the NT and 9x families, employs the Object Manager to organize devices within a hierarchical , where device objects are accessed via paths such as \Device\PhysicalDrive0 for the first physical disk. Users interact with storage devices through drive letters (e.g., C:) rather than direct file-like representations, as the Win32 subsystem abstracts these into the familiar view without exposing the underlying \Device\ paths to most applications. In , which retains DOS compatibility, device handling blends legacy DOS mechanisms with the 32-bit object model, but devices remain distinct from regular files. OS/2 handles devices similarly to DOS through DEVICE= and BASEDEV= statements in , which load base device drivers essential for core hardware like keyboards and disks during boot. For advanced storage, introduces Installable File Systems (IFS) via IFS= statements in , which integrate device drivers with filesystem operations to support diverse media like HPFS volumes, though devices themselves are not uniformly treated as files. Programs in these systems access devices through specialized APIs rather than a universal file interface: DOS relies on Interrupt 21h calls for functions like reading from CON or writing to PRN, while Windows uses CreateFile with device paths (e.g., \.\PhysicalDrive0) to obtain handles for I/O operations. This approach imposes limitations, as devices lack the browsable, uniform file model of systems, requiring separate handling for device-specific operations and preventing seamless integration with standard file tools.

TOS and IOCS

In (The Operating System), the base system provides device access primarily through GEMDOS calls, such as Fopen, Fread, and Fwrite, which treat devices as files using reserved names like CON: for the console, AUX: for the port, and PRN: for the printer. These calls return handles for stream-like I/O operations, with standard handles ranging from to 5; for example, handle represents the console for both input and output, while negative handles like -1 (CON:), -2 (AUX:), and -3 (PRN:) are used specifically for character devices. Unlike systems, base TOS does not employ file nodes in a /dev directory but relies on these predefined handles and names for direct device manipulation without a hierarchical filesystem structure for devices. The Control System (IOCS) in TOS serves as a layer supporting the AES (Application Environment Services) and (Graphics Environment Manager), primarily through the (Basic Input/Output System) for core peripherals and the XBIOS (extended BIOS) for advanced hardware features like enhanced video and sound. functions enable low-level access to devices via integer device codes passed as parameters; for instance, Bconout outputs a character to a specified device, where code 2 denotes the console, 5 the screen, 4 the keyboard, 0 the printer, and 1 the auxiliary port. XBIOS extends this with functions like Mediach (code 8), which detects media changes on disk drives (e.g., returning 0 if unchanged, 1 if possibly changed, or 2 if definitely changed for drives A, B, etc., coded as 0, 1, etc.). These mechanisms abstract hardware details, allowing AES/GEM applications to perform I/O without direct register manipulation, though programmers often use supervisor mode via the Super call for privileged access. Later extensions like MiNT (MiNT is Now TOS), developed in the early and evolving into FreeMiNT, enhance TOS compatibility while introducing features, including /dev-like support for device special files to enable portable Unix applications on hardware. FreeMiNT maintains GEMDOS compatibility but adds a multitasking kernel with device drivers mimicking Unix conventions, such as /dev/null for discarding output and /dev/tty for terminal access, facilitating ports of tools like and . This evolution, driven by community efforts post-Atari's market exit, bridges TOS's proprietary model with Unix standards without requiring file nodes in base TOS.

Implementations and Variations

Traditional Implementations

In traditional systems, the /dev directory was statically populated with device nodes at time using scripts such as MAKEDEV, which invoked the mknod command to create entries for all anticipated hardware devices based on predefined numbers. This approach, prevalent in early kernels up to version 2.4, ensured a fixed set of device files was available immediately after system initialization, supporting essential operations like mounting filesystems and accessing peripherals without runtime generation. However, it required system administrators to manually update scripts for new hardware, often leading to incomplete or outdated configurations on diverse systems. An early step toward dynamic management appeared in BSD variants with the introduction of devfs, an in-kernel virtual filesystem that generated device nodes on demand rather than pre-populating them. First implemented in 2.0 in 1994, devfs integrated device creation directly into the kernel's vnode interface, allowing nodes to appear only when drivers registered devices, thus reducing unnecessary filesystem clutter while maintaining compatibility with traditional /dev access. This mechanism provided a more efficient alternative to static scripts in environments with variable hardware, influencing subsequent Unix derivatives by shifting device enumeration from user-space tools to kernel-level automation. Linux followed a similar path with its own devfs, introduced in kernel version 2.3.46 in 1999 by developer Richard Gooch. This in-kernel filesystem dynamically created and managed device nodes as drivers registered devices, aiming to address the limitations of static population for hotpluggable hardware. However, due to issues with permissions, naming consistency, and integration challenges, devfs saw limited adoption and was deprecated in kernel 2.6.13 (2005), with full removal in kernel 3.5 (2012). The static /dev approach eventually revealed performance drawbacks, including filesystem bloat from thousands of unused nodes for potential devices, which consumed disk space and complicated maintenance as hardware proliferated in the . This inefficiency, coupled with the need for unique major/minor numbers across all possible peripherals, motivated the adoption of around 2003 for 2.6, enabling dynamic node creation based on detected hardware to mitigate resource waste.

Modern and Dynamic Approaches

In modern operating systems, dynamic device file management has evolved to handle hotplug events, automate naming, and enforce security without relying on static configurations. A key advancement in is , a userspace daemon introduced in 2003 as a successor to earlier hotplug mechanisms, which processes kernel device events to create, remove, or modify device nodes in /dev. uses configurable rules files, typically in /etc/udev/rules.d/, to set device names, permissions, , and symlinks based on attributes like vendor ID or device class during hotplug operations, enabling consistent handling of or USB devices. This approach addresses the limitations of traditional static device node creation by responding in real-time to hardware changes, reducing administrative overhead. Integration with , starting from version 197 around 2013 and widely adopted by 2015, further enhances predictability in device naming, particularly for network interfaces. Systemd-udev assigns stable names like enp0s3—indicating an Ethernet device on PCI bus 0, slot 3—based on hardware topology such as paths or slot indices, preventing the kernel's eth0-style from shifting on reboots or reconfigurations. This scheme improves automation in cloud and virtualized environments by ensuring scripts and services reference consistent identifiers. Beyond , other Unix variants have implemented dynamic improvements to their device file systems. introduced an enhanced devfs in 2009, which automatically populates /dev with device nodes on demand, supports path-based access for easier identification, and integrates permission controls directly in the kernel for faster hotplug response compared to earlier implementations. In Solaris (now ), the devfs file system pairs with the devfsadm utility, which dynamically manages /dev entries for hotplugged devices, generates links in /dev/fd and /dev/rmt, and cleans up stale nodes without manual intervention. These tools replace legacy commands like drvconfig, providing a unified for physical and logical devices. Security enhancements in these systems leverage mandatory access controls to restrict sensitive device files. In , SELinux policies deny unauthorized read/write access to /dev/kmem, which exposes kernel and poses risks for rootkits, by labeling it with contexts like system_u:object_r:kmem_device_t and enforcing domain separation—no user domain can map or access it without explicit allowances. Similarly, profiles confine applications by path, such as denying rw access to /dev/kmem or other block devices via rules like "deny /dev/kmem rw," preventing privilege escalations in confined processes. These mechanisms integrate with dynamic managers like , applying policies during device creation to mitigate exploits targeting /dev. Dynamic approaches also extend to containerized environments, where tools like Docker use bind-mounts to selectively expose host /dev entries into isolated namespaces, ensuring containers access only necessary devices (e.g., mounting /dev/null or GPU nodes) without full . This addresses post-2010 gaps in traditional systems by supporting and , where static /dev population would fail under rapid hardware scaling in clouds.

References

  1. https://docs.oracle.com/en/operating-systems/oracle-linux/6/admin/ol_about_devices.html
  2. https://www.physics.udel.edu/~bnikolic/teaching/phys660/RUTE/rute/node21.html
  3. https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-udev.html
  4. https://courses.cs.washington.edu/courses/cse451/TLKCopy/fs/filesystem.html
  5. https://www.ibm.com/docs/en/linux-on-systems?topic=hdaa-names-nodes-numbers-1
  6. https://www.oreilly.com/library/view/linux-device-drivers/0596000081/ch03s02.html
  7. https://dsf.berkeley.edu/cs262/unix.pdf
  8. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/hist.pdf
  9. https://s3.amazonaws.com/plan9-bell-labs/7thEdMan/index.html
  10. https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub151-1.pdf
  11. https://www.usenix.org/legacyurl/rethinking-dev-and-devices-unix-kernel
  12. https://lwn.net/2001/features/OLS/pdf/pdf/devfs.pdf
  13. https://tldp.org/LDP/lkmpg/2.4/html/c577.htm
  14. https://www.xml.com/ldd/chapter/book/ch03.html
  15. https://tldp.org/LDP/lkmpg/2.6/html/x569.html
  16. https://www.kernel.org/doc/Documentation/admin-guide/devices.txt
  17. https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch16.html
  18. https://tldp.org/HOWTO/Partition/devices.html
  19. https://www.kernel.org/doc/gorman/html/understand/understand013.html
  20. https://docs.kernel.org/admin-guide/devices.html
  21. https://man7.org/linux/man-pages/man2/lseek.2.html
  22. https://www.oreilly.com/library/view/linux-device-drivers/0596000081/ch12s06.html
  23. https://www.xml.com/ldd/chapter/book/ch12.html
  24. https://man7.org/linux/man-pages/man4/mem.4.html
  25. https://man7.org/linux/man-pages/man4/full.4.html
  26. https://man7.org/linux/man-pages/man4/random.4.html
  27. https://man7.org/linux/man-pages/man7/pty.7.html
  28. https://man7.org/linux/man-pages/man4/pts.4.html
  29. https://linux.die.net/man/4/port
  30. https://www.kernel.org/doc/Documentation/ABI/testing/dev-kmsg
  31. https://www.ibm.com/docs/en/linux-on-systems?topic=numbers-creating-device-nodes
  32. https://manpages.ubuntu.com/manpages/jammy/man8/MAKEDEV.8.html
  33. https://www.linuxjournal.com/article/2597
  34. https://www.usenix.org/conference/2003-linux-kernel-developers-summit/managing-dynamic-device-naming
  35. https://www.lumensoutdoors.org/posts/2004-10-08-hotplug.html
  36. https://unix.stackexchange.com/questions/394629/how-to-remove-inactive-block-device-from-the-dev
  37. https://tldp.org/HOWTO/SCSI-2.4-HOWTO/dnames.html
  38. https://wiki.archlinux.org/title/Solid_state_drive/NVMe
  39. https://www.freedesktop.org/software/systemd/man/udev.html
  40. https://www.linuxfromscratch.org/lfs/view/12.3/chapter09/udev.html
  41. https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html
  42. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_storage_devices/persistent-naming-attributes_managing-storage-devices
  43. http://dos.packetsniffers.org/DOSPAGE/CNFIGSYS.HTM
  44. https://files.comtrol.com/obsolete/hostess/16_port/drivers/dos/sw_doc/2000092a.pdf
  45. https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
  46. https://stackoverflow.com/questions/36225708/cannot-create-a-directory-named-aux-or-starting-by-aux-on-windows-8-1
  47. https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ns-wdm-_device_object
  48. https://stackoverflow.com/questions/23041983/path-prefixes-and
  49. https://superuser.com/questions/307955/how-do-windows-nt-based-operating-systems-address-devices
  50. https://www.edm2.com/index.php/CONFIG.SYS_-_BASEDEV_Statements
  51. https://www.os2world.com/wiki/index.php/OS/2_2.0_CONFIG.SYS_DESCRIPTION
  52. https://www.edm2.com/index.php/IFS_-_Installable_File_System_Overview
  53. https://www.stanislavs.org/helppc/int_21.html
  54. https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea
  55. https://unix.stackexchange.com/questions/141016/a-laymans-explanation-for-everything-is-a-file-what-differs-from-windows
  56. https://superuser.com/questions/364152/why-is-everything-is-a-file-unique-to-the-unix-operating-systems
  57. http://www.bitsavers.org/pdf/atari/ST/Atari_ST_GEM_Programming_1986/GEM_0042.pdf
  58. https://freemint.github.io/tos.hyp/en/About_the_BIOS.html
  59. https://github.com/freemint/freemint
  60. https://www.linuxfromscratch.org/lfs/view/9.0-systemd/chapter07/udev.html
  61. https://sg.danny.cz/scsi/devfs_scsi.html
  62. https://www.linux.com/news/udev-introduction-device-management-modern-linux-system/
  63. https://superuser.com/questions/686774/what-problems-does-udev-actually-solve
  64. https://man7.org/linux/man-pages/man7/udev.7.html
  65. https://bootlin.com/doc/legacy/udev/udev.pdf
  66. https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
  67. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/networking_guide/sec-understanding_the_predictable_network_interface_device_names
  68. https://www.dragonflybsd.org/docs/developer/devfs/
  69. https://docs.oracle.com/cd/E36784_01/html/E36871/devfsadm-1m.html
  70. https://docs.oracle.com/cd/E19253-01/816-5166/6mbb1kpvd/index.html
  71. http://kernsec.org/files/lss2014/lss2014_androidtcb_smalley.pdf
  72. https://docs.kernel.org/admin-guide/LSM/apparmor.html
  73. https://docs.docker.com/engine/storage/bind-mounts/
  74. https://docs.docker.com/engine/security/apparmor/
Add your contribution
Related Hubs
User Avatar
No comments yet.