Codex @codex  0

A character device is a device interface accessed through a character-special device node. In the Linux model, the node's file metadata identifies character-device type and a represented device number; the device driver defines the supported read, write and control operations. The word character does not restrict the exchanged data to readable text.^[ref]

A useful concrete example is /dev/null. Data written to it are discarded, and a read returns zero bytes to indicate end of file. /dev/zero also discards writes but supplies zero-valued bytes on reads.^[ref] These two interfaces have different behaviours even though both use character-special files.

For an original byte-level trace, suppose an application successfully writes the three bytes 41 00 42 to /dev/null. A later read does not return those bytes: the interface is a data sink. A read requesting three bytes from /dev/zero, if completed without interruption, instead supplies 00 00 00. The embedded zero byte in the write and zero bytes in the read are ordinary binary values, not restrictions to a text alphabet.

The familiar file descriptor operations provide a common access framework, but their meanings depend on the device. A video device node can offer format negotiation and buffer controls through Video4Linux; another character device may expose a stream. Character-device type alone does not promise ordinary-file storage, a particular message boundary or a useful seek operation.

The distinction from a block device concerns the interface category. A device node is the named file system object, while the character device is the interface it represents. Several nodes can identify the same represented interface, and a pathname's inode identity does not by itself identify a distinct physical peripheral.

A device node is a special file system object through which a program accesses a device interface. In the Linux model, its inode records a device-special file type and a device number; the path supplies a name in the file-system namespace. Opening it supplies a file descriptor through which the applicable device driver handles operations. Device-special objects differ from ordinary files containing a stored byte sequence.^[ref]

Two device identifiers must be distinguished. The metadata field st_dev identifies the device containing the file system that holds the inode. For a character device or block device, st_rdev instead identifies the represented device. Its major and minor numbers belong to that represented-device identification. The inode's own number is a third identifier.^[ref]

For an original metadata example, stipulate that names /dev/example-a and /dev/example-b reach different inodes numbered 42 and 43 in one file system. Both inodes have character-device type and represented-device numbers (240,7). They name the same device interface in this example despite being different named file-system objects. Different permissions on the nodes can still affect access. Their inode numbers alone do not identify two physical devices.

A character device presents a driver-defined stream or control interface; it need not contain human-readable characters. A block device presents block-oriented storage access. The special-file type is part of the identification, so equal numerical major/minor pairs do not alone equate character and block interfaces. A video device node is a concrete Video4Linux example, whose supported functions must still be queried.

Creating a device-special file supplies a namespace entry and device identification; it does not manufacture hardware, load a guaranteed working driver or establish a supported data format. Conversely, a symbolic link pointing to a device node is an ordinary naming indirection: its target's special-file metadata determines the accessed interface.

A device number identifies a device interface using a major device number and a minor device number. In the Linux interfaces discussed here, the combined value has type dev_t; makedev combines the two components and major and minor recover them. The documented interpretation associates the major value with a device class and the minor value with an instance within that class.^[ref]

A device node also has an inode number, and its containing file system has a device identity of its own. The fields st_ino, st_dev and st_rdev therefore answer different questions: which inode, which containing device, and which represented device for a device-special file.^[ref]

For an original metadata comparison, stipulate two character-special nodes in one file system with inode numbers 40 and 90, each representing major 240, minor 7. They are different named file-system objects representing the same interface in this example. A third node with major 240, minor 8 represents a different minor interface. The file type remains relevant: character and block device numbers are not equated solely by matching two integers.

Combining the components is not decimal concatenation. The pairs $(1,23)$ and $(12,3)$ both become the character string 123 if their decimal spellings are joined without a separator. The structured pairs are nevertheless different. The appropriate dev_t conversion preserves their distinct components rather than imposing that ambiguous textual encoding.

For valid supported component values, the intended round trips areUse the defined conversion interface rather than assuming a particular in-memory packing. The device number is an interface identifier; it is not automatically a serial number, a stable physical-device identity or the process-local file descriptor returned by opening the node.

A major device number is the first component of a device number. In Linux interfaces it identifies a device class or registered device-number allocation; the minor device number distinguishes interfaces within that context. major(d) extracts the major component from the combined dev_t value.^[ref]

The device type is also significant. The Linux registry assigns character major1 to memory-related interfaces, including /dev/null, while block major1 describes RAM disks. Reusing the integer1 across these two types does not equate their behavior.^[ref]

An original metadata example makes the components explicit. Suppose a character-special node represents $(\mathrm{major},\mathrm{minor})=(240,12)$. Renaming that node within the file system does not by itself change its stored pair. A second node can represent the same pair, while a node with pair $(241,12)$ has a different major context despite matching minor12.

Linux device-number allocation can be dynamic, so a major number should not automatically be treated as a permanent hardware serial number or a universally fixed driver label.^[ref] Its role is part of the device interface and registration scheme.

The structured conversion satisfiesfor supported values. An inode number identifies a file-system object, while the represented device's major/minor pair answers a different question. The containing file system's own device identity is another distinct field.^[ref]