Device file

from Wikipedia, the free encyclopedia

Device files ( English device file ) are special files that under almost all Unix derivatives and many other operating systems are used. They enable simple communication between user space , for example normal user programs , and the kernel and thus ultimately the hardware of a computer . This communication is transparent because device files are used like normal files.

Device files under Unix

Types of device files

The file systems of Unix and similar operating systems differentiate between "normal" files (binary / ASCII), directories , named pipes (also called FIFOs ), symbolic links , sockets and data blocks . While "normal" files and directories are part of the standard functionality of normal file systems, named pipes already play a special role but are not part of the device files. Only the last three types are device files. A distinction is therefore made between three types of device files:

Commands such as lsor are suitable for outputting the type of a (device) file file.

/devin the Konqueror file system browser . You can see the icons of the many different device files

Since there is usually a separate device file for each device, these files were already collected in the directory in early versions of Unix /dev. With the Filesystem Hierarchy Standard , this procedure has been standardized for Linux ( Solaris stores the device files under the virtual file system /devicesand automatically generates symlinks that point from /devto the actual files in /devices), and it is also prescribed which device files must exist in this directory under which name (see the lists below). Modern Unix derivatives often use special (virtual) file systems to keep this directory up to date. For a long time, devfs was popular under Linux , but now udev takes care of the administration of device files.

Device files are used as an interface between device drivers or system components and application programs that run in user space. For example, you can print on an LPT printer, which is connected to the computer via the parallel interface, by writing text directly into the device file /dev/lp0. The concept of device files means that programs are in principle separated from the device drivers that operate in the kernel. In addition, the use of a device appears completely transparent - you don't have to use a special program first, but can write to a file that corresponds to the printer. This enables intuitive use of the hardware.

The concept of device files is one of the foundations for the Unix principle Everything is a file and was expanded, for example, with approaches such as the derivative Plan 9 .

Block-oriented devices

Block Devices (also block storage device, block device or English. Block device ) transfer data in blocks of data and are therefore often used for parallel data transfers used. All of these devices use the operating system's own buffer .

Examples of file names for block-oriented devices
Description of the device Linux FreeBSD NetBSD / OpenBSD macOS Solaris
1.  Floppy disk drive fd0
IDE - hard disk or IDE CD-ROM drive on the first terminal master (in Linux ) hda ad0 wd0
IDE hard disk or IDE CD-ROM drive on the 1st slave connection hdb ad1
1. primary partition of the first IDE hard disk hda1
15. logical partition of the first IDE disk hda15
1.  Slice of the first IDE disk ad0s1
15. Slice of the first IDE disk ad0s15
1st partition in the 1st slice of the first IDE disk ad0s1a
2nd partition in the 1st slice of the first IDE disk ad0s1b
IDE CD-ROM drive on the 1st connection Master acd0
IDE CD-ROM drive on the 1st connection slave acd1
1. SCSI CD-ROM drive scd0 cd0
SCSI - (removable) disk, smallest SCSI ID sda disk0
SCSI - (removable) disk, next higher SCSI ID sdb disk1
1. primary partition of the first SCSI (removable) disk sda1 disk0s0
11. logical partition of the first SCSI (removable) disk sda15
SCSI (removable) disk, smallest SCSI ID da0 disk0
5th partition in the 2nd slice of the 2nd SCSI (removable) disk da1s2e
on the C th SCSI controller with SCSI ID = T the D th hard disk and on it the S th slice cCtTdDsS
symbolic link on CD-ROM drive cdrom
The first namespace of the first registered NVMe device nvme0n1
The first partition of the first namespace of the first registered NVMe device nvme0n1p1

Character oriented devices

Character-oriented devices only transmit one character (typically one byte ) at a time, so they must be assigned to serial data transmission . Usually, but not always, data is transferred unbuffered - i.e. immediately.

Examples of filenames for character devices
Description of the device Linux DOS / Windows macOS
1.  Serial interface ttyS0 COM
1.  Parallel interface lp0 LPT1
2. Parallel interface lp1 LPT2
symbolic links for pseudo terminals ttyX
Device files for USB devices as well as all virtual device files usbdev1.1
symbolic link to mouse device file mouse
File of a frame buffer (e.g. monitor) fbX
Drive file in drawing mode ( macOS ). rdisk0, rdisk1, ... corresponds to the first, second, ... hard disk as a device per se, while rdisk0s1 is, for example, the first partition on the first hard disk. rdisk#


The device controller of the first registered NVMe device nvme0

The network cards ( e.g. Ethernet , ISDN ) are not addressed under Linux via device files, but via the TCP / IP stack ; however, there are often device files for special applications such as direct control of the hardware ( netlink device, D-channel, etc.) .

Socket-oriented devices

For socket-based devices this is not to device files, but a form of interprocess communication . Like FIFOs , they are not device files, but they can also be used to communicate with the kernel and perform a similar task to character-oriented devices.

Examples of socket-oriented devices
Filename meaning
/dev/log Socket for syslog - Daemon
/dev/gpmdata Socket for the GPM mouse multiplexer
/dev/printer Socket for lpd

Fake devices

A device file does not have a real-world device correspond, but can also be a so-called virtual device ( virtual device ) or pseudo device ( pseudo-device available). This is a work tool, the functionality of which is handled by the operating system (kernel, kernel extension, driver).

Contrary to what the term virtual device suggests, a physical device is not necessarily reproduced here (see virtualization ).

The following is a list of the most common pseudodevices (all character-oriented) in Unix and similar systems :

/dev/null discards any input without producing any output
/dev/zero produces a symbol stream consisting of only null characters (in C notation: '\0') consists
/dev/full produces a stream of characters that only consists of null characters (in C notation:) during read access . There is an ENOSPC ("disk full") error during write access. '\0'
/dev/random produces real random numbers or at least cryptographically strong pseudo- random numbers (mostly based on hardware inputs)
/dev/urandom produces pseudo-random numbers (mostly in contrast to /dev/randomwithout blocking, when no hardware data is generated)

Management of device files using Linux as an example

The Linux-specific command mknod is used to create device files and requires the associated major and minor number to create a device file.

If a user installed a new driver in early Linux versions, one or more device files had to be created with this mknodcommand with the aid of the driver documentation and specifying the necessary major / minor number in order to create the required interface. Many Linux distributions therefore /devalready provided thousands of device files in the directory tree, regardless of whether they would ever be needed. On the one hand this was confusing, on the other hand it was difficult to automatically load new drivers for new hardware, since the device files always had to be maintained manually.

Two new concepts have been developed over several years and kernel releases:


The devfs was introduced in the Linux kernel tree 2.2 . The underlying idea was that the kernel modules themselves carry information about the names of the device files they generate, along with the minor and major numbers and type. This enabled the kernel to generate the device files itself for the first time.

The required or provided by the kernel and its modules, device files has then automatically the kernel in the devfs file system using the devfsd - Daemons created. The file system was usually /devmounted in the directory .


After careful consideration, the system with devfs seemed too inflexible. A system was required that reacts when new hardware is plugged in ( hotplugging ), loads the corresponding kernel modules and creates the device files and removes them again when the devices are unplugged. In addition, it should be possible to define by means of a set of rules which naming scheme you want to use for your device files, how they are to be structured in subdirectories, etc.

With the introduction of Kernel 2.6, udev became this new device management concept. Similar to devfs, there is also a daemon that runs in userspace and does the real work. However, udev does not use its own file system, and the necessary kernel component is much leaner, i.e. smaller and simpler.

Device files under Windows

There are also device files under Windows : You can access them as a programmer using the subroutine CreateFile() . The name of a device file has the format \\.\NAME. Device files are not to be found under normal directories, as under Unix, and communication is accordingly not transparent (for the user). As a user, the Windows shell generally has no way of accessing device files.


Web links