Product Code Database
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 Computer 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 . Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions.
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 , 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. Because early versions of MS-DOS did not support a directory hierarchy, devices were distinguished from regular files by making their names 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. 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."
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; 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.
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 are sometimes known as 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.
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.
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:
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.
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 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. 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 , for example, or "see" a networked terminal session as associated with .
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.
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.
MS-DOS borrowed the concept of special files from Unix but renamed them devices. Because early versions of MS-DOS did not support a directory hierarchy, devices were distinguished from regular files by making their names . This means that certain file names were reserved for devices, and should not be used to name new files or directories. 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).
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. 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.
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".
| CON | Receives typed data until Caret notation (Ctrl-Z) is pressed. | Prints data to the console. |
| Prints text to the printer, usually redirected to or . Sometimes reconfigurable to other devices. [1] | ||
| (not in OS/2) | Reads data from an auxiliary device, usually a serial device like . Sometimes reconfigurable to other devices. | Sends data to an auxiliary device, usually a serial device like . Sometimes reconfigurable to other devices. |
| Returns null or no data. | Discards received data. | |
| CLOCK$ (still named CLOCK in some versions of MS-DOS 2.11 (Note: While the publishers claim this would be MS-DOS 1.1 and 2.0, it actually is SCP MS-DOS 1.25 and a mixture of Altos MS-DOS 2.11 and TeleVideo PC DOS 2.11.)) | ||
| KEYBD$ (only in multitasking MS-DOS) | ||
| KBD$ (only in OS/2) | ||
| SCREEN$ (only in multitasking MS-DOS and OS/2) | ||
| POINTER$ (only in OS/2) | ||
| MOUSE$ (only in OS/2) | ||
| $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) | ||
| (only in 86-DOS and DOS 1.x, also in Hewlett-Packard's MS-DOS 2.11 for the HP Portable Plus) | Returns no data. | Sends data to the line printer. (LPT2 for Hewlett-Packard's MS-DOS 2.11) |
| PLT (only in Hewlett-Packard's MS-DOS 2.11 for the HP Portable Plus) | Returns no data. | Sends data to the assigned plotter. The attached plotter device is reconfigurable. |
| , , , and sometimes (in DR-DOS 7.02 and higher and some versions of Multiuser DOS) | Sends data to the selected parallel port. | |
| , , , | 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) | 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:
PIPE, MAILSLOT, and MUP are other standard Windows devices.
|
|
