Device file

From HandWiki
Short description: Interface to a device driver that appears in a file system as if it were an ordinary file


In Unix-like operating systems, a device file 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

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, for example: the infamous CON. These were chosen for a degree of compatibility with CP/M and are still present in modern Windows for backwards compatibility.

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;[2] 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.[3]

Unix and Unix-like systems

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,[4] 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:[5] 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.[6] 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,[7] while the latter creates only block devices. In Linux, to get a character device for a disk, one must use the "raw" driver, though one can get the same effect as opening a character device by opening the block device with the Linux-specific O_DIRECT flag.

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 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:

  • /dev/pf – allows userland processes to control PF through an ioctl interface.
  • /dev/bio – provides ioctl access to devices otherwise not found as /dev nodes, used by bioctl to implement RAID management in OpenBSD and NetBSD.
  • /dev/sysmon – used by NetBSD's envsys framework for hardware monitoring, accessed in the userland through proplib(3) by the envstat utility.[8]

Node creation

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).

While some other Unix systems such as FreeBSD, used kernel-based device node management via devfs only, and not supporting 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.[9]

Naming conventions

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

  • lp: line printers (compare lp)
  • pt: pseudo-terminals (virtual terminals)
  • tty: terminals

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 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
    • hdd: the slave 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.[10]

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 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

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.[11] 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).[12]

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.[13] 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.[14]

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[13] Use as input Use as output
CON Receives typed data until ^Z (Ctrl-Z) is pressed. Prints data to the console.
PRN[15] N/A Prints text to the printer, usually redirected to LPT1 or LST. Sometimes reconfigurable to other devices.[16][17][18]
AUX (not in OS/2[15]) Reads data from an auxiliary device, usually a serial device like COM1. Sometimes reconfigurable to other devices.[16][17][18] Sends data to an auxiliary device, usually a serial device like COM1. Sometimes reconfigurable to other devices.[16][17][18]
NUL Returns null or no data. Discards received data.
publisher=Computer History Museum, Microsoft |date=2013-12-19 |orig-date=1983 |access-date=2014-03-25}} (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.)</ref>[16][17]) N/A N/A
KEYBD$ (only in multitasking MS-DOS) ? ?
KBD$ (only in OS/2[15]) ? ?
SCREEN$ (only in multitasking MS-DOS and OS/2[15]) ? ?
POINTER$ (only in OS/2[15]) ? ?
MOUSE$ (only in OS/2[15]) ? ?
$IDLE$ (only in DR-DOS (since 5.0) and Multiuser DOS (since Concurrent DOS 386) families) N/A N/A
CONFIG$ (only in MS-DOS 7.0 and higher) N/A N/A
LST (only in 86-DOS and DOS 1.x, also in Hewlett-Packard's MS-DOS 2.11 for the HP Portable Plus[16][17]) Returns no data. Sends data to the line printer. (LPT2 for Hewlett-Packard's MS-DOS 2.11[16][17])
PLT (only in Hewlett-Packard's MS-DOS 2.11 for the HP Portable Plus[16][17]) Returns no data. Sends data to the assigned plotter. The attached plotter device is reconfigurable.[16][17]
LPT1, LPT2, LPT3, and sometimes LPT4 (in DR-DOS 7.02 and higher and some versions of Multiuser DOS) N/A 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[16][17]) 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.[19]

IOCS

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).[20]

Implementations

Operating System Filesystem or managing software Standard mount point Author Notes
Linux 2.3.46pre5–2.6.17 devfs[21] and devfsd /dev Richard Gooch Implemented fully in the kernel, with optional daemon devfsd to handle device node events in user space.[22] 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[23]
Solaris devfs[24] /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[25] 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[26][27] 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


References

  1. ↑ 1.0 1.1 "Windows for Workgroups: How VSHARE.386 Manages File Sharing". Support.microsoft.com. 1999-09-22. http://support.microsoft.com/kb/90239. 
  2. ↑ Kroah-Hartman, Greg (2005-06-20). "[PATCH devfs: Remove devfs from the kernel tree"]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/devfs?id=d8deac5094988c7ad1127ee61f52c59a952fcabb. 
  3. ↑ Corbet, Jonathan; Kroah-Hartman, Greg; Rubini, Alessandro (2005). Linux Device Drivers, 3rd Edition. O'Reilly. http://www.makelinux.net/ldd3/chp-6-sect-6.shtml. Retrieved 28 April 2017. "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." 
  4. ↑ The UNIX Programming Environment. Prentice-Hall. 1984. p. 66. ISBN 0-13-937681-X. https://archive.org/details/unixprogramminge0000kern/page/66. 
  5. ↑ Neil Brown (October 27, 2010). "Ghosts of Unix Past: a historical search for design patterns". https://lwn.net/Articles/411845/. 
  6. ↑ "IEEE Std 1003.1, 2013 Edition". http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_79. 
  7. ↑ "FreeBSD Architecture Handbook". http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html. 
  8. ↑ "usr.sbin/envstat/envstat.c". NetBSD. November 2021. http://bxr.su/n/usr.sbin/envstat/envstat.c. 
  9. ↑ "mknod(8)". The FreeBSD Project. 2016-10-03. https://www.freebsd.org/cgi/man.cgi?query=mknod&apropos=0&sektion=8&manpath=FreeBSD+13.0-RELEASE&arch=default&format=html. 
  10. ↑ Linux Assigned Names and Numbers Authority (2009-04-06). "Linux allocated devices (2.6+ version)". Linux kernel (Documentation/devices.txt). https://www.kernel.org/doc/Documentation/devices.txt. 
  11. ↑ "Avoid Creating Macintosh Filenames that are NT Device Names". Support.microsoft.com. 2006-11-01. http://support.microsoft.com/kb/120740/a. 
  12. ↑ "device attributes". Stanislavs.org. http://stanislavs.org/helppc/device_attributes.html. 
  13. ↑ 13.0 13.1 "MS-DOS Device Driver Names Cannot be Used As File Names". Microsoft. 2003-05-12. http://support.microsoft.com/kb/74496/en-us. 
  14. ↑ "Undocumented Commands". 4dos.info. Kevtronics. 2002-04-12. http://www.4dos.info/tools/undoc_dos.txt. 
  15. ↑ 15.0 15.1 15.2 15.3 15.4 15.5 IBM Operating System/2 Technical Reference - Programming Family. 1 (1st ed.). IBM. September 1987. http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/pc/os2/84X1434_OS2_Technical_Reference_Volume_1_Sep87.pdf. 
  16. ↑ 16.0 16.1 16.2 16.3 16.4 16.5 16.6 16.7 16.8 Hewlett-Packard - Technical Reference Manual - Portable PLUS (1 ed.). Corvallis, OR, USA: Hewlett-Packard Company, Portable Computer Division. August 1985. 45559-90001. https://archive.org/details/bitsavers_hpportableblePLUSTechnicalReferenceManualAug1985_25919880. Retrieved 2016-11-27. 
  17. ↑ 17.0 17.1 17.2 17.3 17.4 17.5 17.6 17.7 17.8 Hewlett-Packard - Technical Reference Manual - Portable PLUS (2 ed.). Portable Computer Division, Corvallis, OR, USA: Hewlett-Packard Company. December 1986. 45559-90006. http://www.jeffcalc.hp41.eu/hpplus/files/techrefman.pdf. Retrieved 2016-11-27. 
  18. ↑ 18.0 18.1 18.2 "Caldera OpenDOS 7.01/7.02 Update Alpha 3 IBMBIO.COM README.TXT". 1997-10-02. http://www.uni-bonn.de/~uzs180/download/ibmbioa3.zip.  [1]
  19. ↑ "REG: CurrentControlSet Entries PART 2: SessionManager". Support.microsoft.com. 2006-11-01. http://support.microsoft.com/kb/102985. 
  20. ↑ Technical Reference Manual PC-E500. Sharp Corporation, Information Systems Group, Personal Equipment Division. March 1990. p. 17. http://www.sarnau.info/static/files/TechnicalReferenceManualPC-E500.pdf. Retrieved 2017-03-14. 
  21. ↑ Gooch, Richard (2002-08-20). "Linux Devfs (Device File System) FAQ". https://www.safe-mbox.com/~rgooch/linux/docs/devfs.html. 
  22. ↑ Gooch, Richard. "My Linux Contributions". https://www.safe-mbox.com/~rgooch/linux/. "Devfsd provides configurable management of device nodes using the Linux Device Filesystem." 
  23. ↑ "Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev". LWN. https://lwn.net/Articles/345480/. 
  24. ↑ "devfs(7FS)". Oracle. 2014. https://docs.oracle.com/cd/E36784_01/html/E36884/devfs-7fs.html. 
  25. ↑ "Project Black change log". https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/HWSupport/DeviceFS/BlackLog?rev=4.1;content-type=text%2Fplain. 
  26. ↑ "The drive U: in MagiC". 2016-03-28. http://toshyp.atari.org/en/00b00b.html. 
  27. ↑ "FreeMiNT-Portal - mint.doc". 2000-04-27. http://freemint.de/docs/mint.mint_doc.html. 

Further reading



Retrieved from "https://handwiki.org/wiki/index.php?title=Device_file&oldid=3385769"