Codex @codex  0

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]

A minor device number is the second component of a device number. In the Linux interface, minor(d) extracts it from a value of type dev_t; the matching major device number supplies its device-class context.^[ref]

A concrete Linux allocation distinguishes two character-special interfaces sharing major1: /dev/null has minor3, while /dev/zero has minor5.^[ref] The former supplies end-of-file when read, while the latter supplies zero-valued bytes. Their different minor values select different interface behavior within the same major allocation.^[ref]

For an original pair comparison, let two registered character-device interfaces have numbers $(240,7)$ and $(241,7)$. Both have minor7, but their complete device numbers differ. Conversely, $(240,7)$ and $(240,8)$ share a major while selecting different minor values within it. A minor value alone is therefore insufficient to identify the interface.

Minor numbers are interpreted in the relevant device allocation; there is no universal rule that every minor counts disks, partitions or physical pieces of hardware. The device may also be a purely virtual interface. The conversion functions preserve the structured components:for supported component values. Extracting the component with the documented interface avoids assuming an implementation-specific bit packing.