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, 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: 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 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 Block special files or
block devices provide buffered access to hardware devices, and provide some abstraction from their specifics. 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, 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 flag.
Pseudo-devices 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: • accepts and discards all input written to it; provides an
end-of-file indication when read from. • accepts and discards all input written to it; produces a continuous stream of
null characters (zero-value bytes) as output when read from. • produces a continuous stream of null characters (zero-value bytes) as output when read from, and generates an ("disk full") error when attempting to write to it. • produces bytes generated by the kernel's
cryptographically secure pseudorandom number generator. Its exact behavior varies by implementation, and sometimes variants such as or are also provided. • , , access the process's
standard streams. •
n accesses the process's
file descriptor n. • references the current process's controlling terminal device, if it has one, whether or not the process has any open file descriptors that refer to it The
POSIX standard requires only three device special files by name, , and , but does not require that be either readable or writable. A usable system may have many more. Additionally, BSD-specific pseudo-devices with an interface may also include: • allows userland processes to control
PF through an interface. • provides access to devices otherwise not found as nodes, used by to implement
RAID management in
OpenBSD and
NetBSD. • used by NetBSD's
envsys framework for
hardware monitoring, accessed in the userland through by the utility.
Node creation Nodes are created by the
system call. The command-line program for creating nodes is also called . Nodes can be moved or deleted by the usual filesystem system calls (, ) and
commands (, ). Some Unix versions include a script named
makedev or
MAKEDEV to create all necessary devices in the directory . 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. system call and command exist to keep compatibility with POSIX, but manually created device nodes outside devfs will not function at all.
Naming conventions The following prefixes are used for the names of some devices in the hierarchy, to identify the type of device: • :
line printers (compare
lp) • :
pseudo-terminals • :
terminals Some additional prefixes have come into common use in some operating systems: • :
frame buffer • : (platform)
floppy disks, though this same abbreviation is also commonly used to refer to
file descriptor • : ("classic")
IDE driver (previously used for ATA
hard disk drive, ATAPI
optical disc drives, etc.) • : the primary device on the first
ATA channel (usually identified by major number 3 and minor number 0) • : the secondary device on the first ATA channel • : the primary device on the second ATA channel • : the secondary device on the second ATA channel • , :
parallel ports • :
physical memory • : kernel
virtual memory • :
Network block device: Abstraction that represents block devices that are mounted through the network (or from images using qemu-nbd) •
NVMe driver: • : first registered device's device controller (character device) • : first registered device's first namespace (block device) • : first registered device's first namespace's first partition (block device) •
MMC driver: • : storage driver for
MMC media (
SD cards, eMMC chips on laptops, etc.) • : first registered device • : first registered device's first partition •
SCSI driver, also used by
libATA (modern
PATA/
SATA driver) in Linux,
USB,
IEEE 1394, etc.: • : mass-storage driver (block device) • : first registered device • , etc.: second, third, etc. registered devices • : Enclosure driver • : generic SCSI layer • : "ROM" driver (data-oriented optical disc drives; scd is just a secondary alias) • :
magnetic tape driver • : direct access device (disk) • : sequential access device (tape) • : passthrough driver • :
terminals • : (platform)
serial port driver • : 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 directory nodes for the Linux operating system. For most devices, this prefix is followed by a number uniquely identifying the particular device. In Linux, a letter is used to identify devices and is followed by a number to identify
partitions, for hard disk drives. Thus a file system may "know" an area on a disk as , for example, or "see" a networked terminal session as associated with . While other implementations generally use numbers for disk device nodes; in this case, the disk partitions are identified by a subsidiary number, such as , . 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 , , etc.
devfs 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==