What You Will Learn

Prerequisites

Everything Is (Almost) a File

One of the defining ideas behind Unix, and by extension Linux, is that hardware devices should be accessible through the same file-based interface as regular files: open(), read(), write(), and close(). Instead of every application needing a custom API for every peripheral, a serial port, a temperature sensor, or a disk controller can all be manipulated using ordinary file operations. The one well-known exception is networking — network interfaces are accessed through sockets, not device nodes, because the socket API is a better fit for packet-oriented, connection-based communication.

A device node (sometimes called a “special file”) is the entry in the filesystem that represents one of these devices. It doesn’t hold data the way a regular file does; instead, when a program opens it, the kernel routes that open call to the driver responsible for the underlying hardware. The conventional location for these nodes is the /dev directory, though on a minimal staged root filesystem you may be creating /dev from scratch yourself.

Character Devices vs Block Devices

Every non-network device node falls into one of two categories:

A character device is, loosely, “anything that isn’t a block device and isn’t a network interface.” Block devices are specifically mass-storage devices, because only mass storage benefits from the page cache, I/O scheduling, and partition tables that the block layer provides.

Major and Minor Numbers

Every device node carries two numbers that the kernel uses to route requests to the correct driver:

• Major number — identifies which driver handles the device. Historically it mapped to a specific driver, though modern Linux increasingly uses dynamically allocated majors for many driver classes.
• Minor number — identifies which specific instance of that driver’s device you mean, since one driver can back multiple physical devices (e.g. ttyS0, ttyS1, ttyS2).

The kernel documents standard allocations for well-known devices in its source tree, in Documentation/admin-guide/devices.txt (this has moved location across kernel versions, so it’s always worth checking your specific kernel’s documentation directory rather than trusting an old book). You can also inspect currently registered major numbers live on a running system:

$ cat /proc/devices
Character devices:
  1 mem
  4 /dev/vc/0
  4 tty
  4 ttyS
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
 10 misc
...
Block devices:
259 blkext
  8 sd
 11 sr
259 nvme

Creating Device Nodes With mknod

The mknod command (“make node”) creates a device node manually. Its syntax is:

mknod <name> <type> <major> <minor>

Where type is c for a character device or b for a block device. Creating a node requires root privileges, since it grants direct access to kernel-managed hardware routing. Let’s walk through a realistic example: building the two device nodes every minimal root filesystem needs to boot with a shell — console and null.

$ mkdir -p ~/ep_rootfs/dev
$ cd ~/ep_rootfs
$ sudo mknod -m 666 dev/null c 1 3
$ sudo mknod -m 600 dev/console c 5 1
$ ls -l dev
total 0
crw------- 1 root root 5, 1 Aug 13 10:02 console
crw-rw-rw- 1 root root 1, 3 Aug 13 10:02 null

Notice the -m flag: it sets the file mode (permissions) at creation time, the same way chmod would afterwards. /dev/console is restricted to 600 (owner read/write only) because it’s the system console and should only be touched by root. /dev/null is 666 (read/write for everyone) because any process on the system should be able to discard output or read an empty stream from it.

To remove a device node, there is no special “unmknod” command — since a node is just a special kind of directory entry, the ordinary rm command works fine:

$ sudo rm dev/console

Why You Rarely Run mknod by Hand Today

On a full desktop or server Linux distribution, you will almost never run mknod yourself. Two mechanisms handle this automatically:

• devtmpfs — a kernel-managed virtual filesystem, mounted at /dev, that automatically creates a node the moment a driver registers a device, and removes it when the device goes away. Most modern kernels mount this by default very early in boot.
• udev (or its lighter cousin mdev in BusyBox-based systems) — a user-space daemon that listens for kernel uevents and can apply naming rules, symlinks, and permission policies on top of what devtmpfs creates.

Manual mknod still matters in two situations you’ll actually run into as an embedded developer: bootstrapping a minimal root filesystem before any device manager is running (you need at least console and null to get a shell up), and creating nodes inside containers or chroots that don’t have their own kernel driver events to react to.

Common Mistakes and Troubleshooting

Best Practices

• Prefer letting devtmpfs/udev manage /dev on any system where a kernel is fully booted — reserve manual mknod for the minimal early-boot nodes.
• Keep permissions as tight as the use case allows; don’t default to 666.
• Document any manually created nodes in your build scripts so the root filesystem is reproducible, rather than hand-crafting /dev interactively and forgetting what you did.

Security Considerations

Device nodes are a direct line into kernel-managed hardware, so their permissions are a real attack surface. A world-writable node for a storage device or a raw memory device (/dev/mem-style nodes) can let an unprivileged process read or corrupt data far outside its normal reach. When you are building a custom root filesystem, audit every node’s mode explicitly rather than copying a permissions scheme from an unrelated project.

Summary and Key Takeaways

• Device nodes let user space talk to drivers using ordinary file operations — network interfaces are the one exception, handled via sockets instead.
• Nodes are either character (c) or block (b) devices, distinguished by their access pattern.
• Major numbers select the driver; minor numbers select the specific device instance.
• mknod <name> <type> <major> <minor> creates a node manually; rm deletes one.
• A minimal bootable root filesystem needs at least console and null.
• devtmpfs and udev/mdev automate node creation on a running system — manual mknod is mainly for early boot and minimal environments.

Conclusion

Device nodes are one of those pieces of Linux plumbing that quietly make the “everything is a file” philosophy actually work. For most day-to-day development you’ll rely on devtmpfs and udev to manage /dev automatically, but understanding how to create nodes by hand with mknod — and exactly what major and minor numbers mean — is essential once you’re staging a minimal root filesystem from scratch, which is exactly the kind of hands-on skill this free linux device drivers course is built around. In the next lecture, we’ll look at the proc and sysfs pseudo filesystems, which give you an entirely different, dynamic window into kernel state.

Frequently Asked Questions