InUnix-likeoperating systems, adevice file,device node, orspecial file is aninterface to adevice driver that appears in afile system as if it were an ordinaryfile. There are also special files inDOS,OS/2, andWindows. These special files allow an application program to interact with a device by using its device driver via standardinput/outputsystem calls. Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions.
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 asdisk partitions. Additionally, device files are useful for accessingsystem resources that have no connection with any actual device, such asdata sinks andrandom number generators.
There are two general kinds of device files in Unix-like operating systems, known ascharacter special files andblock 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 calleddevice special files in contrast tonamed 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 themdevices.[1] Because early versions of MS-DOS did not support adirectory hierarchy, devices were distinguished from regular files by making their namesreserved words that cannot be used as folder or file names; for example: the wordCON is a reserved word. These were chosen for a degree of compatibility withCP/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.
InWindows XP, entering "Con" into theRun 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] InWindows 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 avirtual 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. TheFreeBSD,DragonFly BSD andDarwin have a dedicated file systemdevfs; device nodes are managed automatically by this file system, inkernel space. Linux used to have a similardevfs implementation, but it was abandoned later, and then removed since version 2.6.17;[3] Linux now primarily uses auser space implementation known asudev, but there are many variants.
In Unix systems which supportchroot process isolation, such asSolaris 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 ofaccess control than Unixfile system permissions).
MS-DOS managed hardware device contention (seeterminate-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 ofdevice driver semantics are implemented in Unix and Linux concerningconcurrent access.[4]
Device nodes correspond to resources that an operating system'skernel has already allocated. Unix identifies those resources by amajor number and aminor number,[5] both stored as part of the structure of anode. The assignment of these numbers occurs uniquely in differentoperating systems and on differentcomputer 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 ofdynamic number allocation, this may not be the case (e.g. onFreeBSD 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 special files orcharacter 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 asraw 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 special files orblock 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-specificO_DIRECT flag.
Device nodes on Unix-like systems do not necessarily have to correspond tophysical devices. Nodes that lack this correspondence are calledpseudo-devices. They provide various functions handled by the operating system. Some of the most commonly used (character-based) pseudo-devices include:
Additionally, BSD-specific pseudo-devices with anioctl interface may also include:
Nodes are created by themknodsystem call. The command-line program for creating nodes is also calledmknod. Nodes can be moved or deleted by the usual filesystem system calls (rename,unlink) andcommands (mv,rm).
Some Unix versions include a script namedmakedev orMAKEDEV 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 asFreeBSD use kernel-based device node management via devfs only and do not support manual node creation.mknod(2) system call andmknod(8) command exist to keep compatibility with POSIX, but manually created device nodes outside devfs will not function at all.[10]
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:
The canonical list of the prefixes used in Linux can be found in theLinux 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 identifypartitions. 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 PCmaster 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 someBSD systems, the IDE devices are named/dev/wd0,/dev/wd1, etc.
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.
A device file is a reserved keyword used inPC DOS,TOS,OS/2, andWindows systems to allow access to certain ports and devices.
MS-DOS borrowed the concept of special files from Unix but renamed themdevices.[1] Because early versions of MS-DOS did not support adirectory hierarchy, devices were distinguished from regular files by making their namesreserved 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 ofPIP command inCP/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 ofMS-DOS provide theAVAILDEVCONFIG.SYS parameter that, if set toFALSE, 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 ofAtari 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). InMiNT andMagiC, 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 toLPT1 orLST. Sometimes reconfigurable to other devices.[17][18][19] |
| AUX (not in OS/2[16]) | Reads data from an auxiliary device, usually a serial device likeCOM1. Sometimes reconfigurable to other devices.[17][18][19] | Sends data to an auxiliary device, usually a serial device likeCOM1. Sometimes reconfigurable to other devices.[17][18][19] |
| NUL | Returns null or no data. | Discards received data. |
| CLOCK$ (still namedCLOCK in some versions of MS-DOS 2.11[20][17][18]) | — | — |
| KEYBD$ (only inmultitasking MS-DOS) | ? | ? |
| KBD$ (only inOS/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 inDR-DOS (since 5.0) andMultiuser DOS (sinceConcurrent DOS 386) families) | — | — |
| CONFIG$ (only in MS-DOS 7.0 and higher) | — | — |
| LST (only in86-DOS and DOS 1.x, also in Hewlett-Packard's MS-DOS 2.11 for theHP 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 theHP Portable Plus[17][18]) | Returns no data. | Sends data to the assignedplotter. The attached plotter device is reconfigurable.[17][18] |
| LPT1,LPT2,LPT3, and sometimesLPT4 (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 theHP Portable Plus[17][18]) | Redirects to COM2. | Redirects to COM2. |
Using shellredirection and pipes, data can be sent to or received from a device. For example, typing the following will send the filec:\data.txt to the printer:
TYPE c:\data.txt > PRN
PIPE, MAILSLOT, and MUP are other standard Windows devices.[21]
The 8-bit operating system ofSharppocket computers like thePC-E500,PC-E500S etc. consists of aBASIC interpreter, a DOS 2-like File Control System (FCS) implementing a rudimentary12-bit FAT-like filesystem, and a BIOS-likeInput/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]
| Operating System | Filesystem or managing software | Standardmount point | Author | Notes |
|---|---|---|---|---|
| Linux 2.3.46pre5–2.6.17 | devfs[23] anddevfsd | /dev | Richard Gooch | Implemented fully in the kernel, with optional daemondevfsd to handle device node events in user space.[24] Obsolete – users are encouraged to migrate toudev and/ordevtmpfs. |
| Linux 2.5– | udev on any fs, but usuallytmpfs | /dev | Greg Kroah-Hartman,Kay Sievers andDan Stekloff | Implemented largely in user space, device information is gathered fromsysfs. 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, theCONFIG.SYSAVAILDEV=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 ofWindows 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. |
The next step beyond a single-open device is to let a single user open a device in multiple processes but allow only one user to have the device open at a time.
Devfsd provides configurable management of device nodes using the Linux Device Filesystem.
