Device file

In Unix-like operating systems, a device file or special file is an interface for a device driver that appears in a file system as if it were an ordinary file. There are also special device files in MS-DOS and Microsoft Windows. They allow software to interact with a device driver using standard input/output system calls, which simplifies many tasks and unifies user-space I/O mechanisms.

Device files often provide simple interfaces to peripheral devices, such as printers and serial ports. But they can also be used to access specific resources on those devices, such as disk partitions. Finally, device files are useful for accessing system resources that have no connection with any actual device such as data sinks and random number generators.

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.^[2] 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 MS-DOS: Block Devices (used for disk drives) and Character Devices (generally all other devices, including COM and PRN devices).^[3] PIPE, MAILSLOT, and MUP are other standard Windows devices.^[4]

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 data written to them and read from them is processed 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.

Implementation

By definition, device nodes correspond to resources that an operating-system kernel has already allocated. Unix identifies those resources by a major number and a minor number^{[citation needed]} (e.g. where the major and minor number of /dev/urandom is 1 and 9 respectively^[5] which may be ascertained using stat /dev/urandom, see mknod), 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, differentiated by the type of hardware with which they interface and the way the operating system processes input and output operations: character devices and block devices.

Character devices

Character special files or character devices relate to devices through which the system transmits data one character at a time by, for example getchar. These device nodes often serve for stream communication with devices such as mice, keyboards, virtual terminals, and serial modems, and usually do not support random access to data.

In most implementations, character devices use unbuffered input and output routines. The system reads each character from the device immediately or writes each character to the device immediately.

Block devices

Block special files or block devices correspond with devices that move data in the form of blocks by, for example, fread. These device nodes interface the devices, such as hard disks, CD-ROM drives, flash drives and other addressable regions of memory.

Block devices support random access and seeking, and generally use buffered input and output routines. The operating system allocates a data buffer to hold a single block each for input and output. When a program sends a request to read data from or to write data to the device, the system stores each character of that data in the appropriate buffer. When the buffer fills up, the appropriate operation takes place (data transfer) and the system clears the buffer.

Pseudo-devices

Device nodes on Unix-like systems do not necessarily have to correspond to physical devices. Nodes that lack this correspondence form the group of 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; produces no output.

/dev/zero

Produces a continuous stream of NUL (zero value) bytes.

/dev/random

Produces a variable-length stream of pseudo-random or truly random numbers. (Blocking)

/dev/urandom

Produces a variable-length stream of pseudo-random numbers. (Non-Blocking)

/dev/full

Produces a continuous stream of NUL (zero value) bytes when read, and returns a "disk full" message when written to.

Node creation

Nodes are created by the mknod system call. The command-line program for creating nodes has the same name. Nodes can be moved or deleted by the usual filesystem system calls (rename, unlink) and commands (mv, rm). When passed the option -R or -a while copying a device node, the cp -l command creates a new device node with the same attributes of the original.

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 are statically assigned major numbers (e.g. by means of hardcoding it in their kernel module).

Linux Naming conventions

The following prefixes have come into common use in Linux-based systems, to identify the type of a device driver interface in the /dev hierarchy:

• 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 master device on the first ATA channel (usually identified by major number 3 and minor number 0)
  • hdb: the slave device on the first ATA channel
  • hdc: the master device on the second ATA channel
    • hdc1: first partition on this disk (example)
    • hdc5: first logical drive in the extended partition (example)
  • hdd: the slave device on the second ATA channel
• lp: line printers (compare lp)
• parport, pp: parallel ports
• pt: pseudo-terminals (virtual terminals)
• SCSI driver, also used by libata (modern PATA/SATA driver), USB, IEEE 1394, etc.
  • sd: mass-storage driver
    • sda: first registered device
      • sda4: last partition on this disk (example)
      • sda6: second logical drive in the extended partition (example)
  • 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 these prefixes can be found in the Linux Device List, the official registry of allocated device numbers and /dev directory nodes for the Linux operating system.^[6]

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

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 general-purpose file system is inconvenient, and as it needs kernel assistance anyway, the idea of a special-purpose file system that is not stored on disk arose.

Also defining when devices are ready to appear is not entirely 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.

Implementations

Operating System	Filesystem or managing software	Standard mount point	Author	Notes
Linux 2.3.46pre5–2.6.17	devfs	/dev	Richard Gooch[disambiguation needed ]	Implemented fully in the kernel. DEPRECATED: Users are encouraged to migrate to udev.
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[7]
Solaris		/dev	Sun Microsystems
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.
Mac OS X	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 kernel. Cannot be mounted elsewhere or unmounted.
MS-DOS, PC DOS, DR-DOS		\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.
Windows 9x		\\devices\	Microsoft

Device files

A device file is a reserved keyword used in MS-DOS and MS-DOS–based systems to allow access to certain ports and devices.

MS-DOS uses device files for access to 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.^[8] A common misconception is that these are bugs which Microsoft has failed to fix.

Device keyword[8]	Use as input	Use as output
CON	Receives typed data until ^Z (Ctrl-Z) is pressed.	Prints data to the console.
PRN	N/A	Prints text to the printer.
AUX	Reads data from an auxiliary device, usually a serial port.	Sends data to an auxiliary device, usually a serial port.
NUL	Returns null or no data.	Discards received data.
CLOCK$	Returns system real-time clock.	N/A
LPT1 (also 2–9)	Reads data from the selected parallel port	Sends data to the selected parallel port
COM1 (also 2–9)	Reads data from the selected serial port	Sends data to the selected serial port

Using shell redirection and pipes, data can be sent to or received from a device. For example, typing 'type c:\data.txt > PRN' will send the file c:\data.txt to the printer, although this may not work on all systems or printers.

See also

Sysfs Block size Blocking Buffer File system

Hardware abstraction User space Unix file types udev

References

1. ^ [1]
2. ^ [2]
3. ^ [3]
4. ^ [4]
5. ^ urandom(4) – Linux Special Files Manual
6. ^ Linux Assigned Names and Numbers Authority (2009-04-06). "Linux allocated devices (2.6+ version)". Linux kernel (Documentation/devices.txt). http://lxr.linux.no/linux/Documentation/devices.txt. Retrieved 2010-11-04. 
7. ^ http://lwn.net/Articles/345480/ , retrieved August 10, 2009
8. ^ ^{a b} "MS-DOS Device Driver Names Cannot be Used as File Names". Microsoft. 2003-05-12. http://support.microsoft.com/kb/74496. Retrieved 2008-05-01. 

Further reading

• Philip Streck (2002-09-24). "devfs for Management and Administration". Linux Journal. http://www.linuxjournal.com/article/6035. 
• Daniel Robbins (2001-10-01). "Part 4: Introduction to devfs". Common threads: Advanced filesystem implementor's guide. IBM. http://www-128.ibm.com/developerworks/library/l-fs4.html. 
• Daniel Robbins (2001-10-01). "Part 5: Setting up devfs". Common threads: Advanced filesystem implementor's guide. IBM. http://www-128.ibm.com/developerworks/library/l-fs5.html. 
• Daniel Robbins (2001-10-01). "Part 6: Implementing devfs (using the init wrapper)". Common threads: Advanced filesystem implementor's guide. IBM. http://www-128.ibm.com/developerworks/linux/library/l-fs6/. 
• Doug Gilbert (2001-01-22). "DEVFS and SCSI". http://sg.danny.cz/scsi/devfs_scsi.html. 
• "3.3. Device Names in devfs". The Linux 2.4 SCSI subsystem HOWTO: Chapter 3. Names and Addresses. Linux Documentation Project. http://tldp.org/HOWTO/SCSI-2.4-HOWTO/dnamesdevfs.html. 
• "Device File System Guide". Gentoo Linux Documentation. Gentoo Foundation, Inc.. http://www.gentoo.org/doc/en/devfs-guide.xml. 
• Mark Ellis (2003-09-23). "How to use kernel module autoloading with devfs and devfsd". Linux From Scratch Hints. http://www.linuxfromscratch.org/hints/downloads/files/devfs+kernel_modules.txt. 
• Martial Daumas (2003-09-18). "How to create a basic mk_initrd command that works nice with LFS and devfs". Linux From Scratch Hints. http://www.linuxfromscratch.org/hints/downloads/files/mk_initrd+devfs.txt. 
• Jeroen Coumans (2003-04-19). "How to setup devfs with your current LFS-configuration using devfsd. How you can use devfs from scratch.". Linux From Scratch Hints. http://www.linuxfromscratch.org/hints/downloads/files/devfs.txt. 
• Tushar Teredesai (2003-03-05). "Using devfs and devfsd". Linux From Scratch Hints. http://www.linuxfromscratch.org/hints/downloads/files/devfsd.txt. 

External links

• FAQ about Linux devfs