What You Will Learn

Prerequisites

This lecture assumes you have worked through the character, block, and network device numbering lectures earlier in this free embedded Linux course.

/proc/devices: The Registration Table

The most direct view into the kernel’s driver registration tables is /proc/devices. It lists every currently registered character major, followed by every currently registered block major, exactly as they exist in the two separate namespaces discussed in earlier lectures.

$ cat /proc/devices
Character devices:
  1 mem
  4 /dev/vc/0
  4 tty
  4 ttyS
 13 input
 89 i2c
180 usb
253 ep_blockdemo

Block devices:
  8 sd
  9 md
259 blkext

Notice this file only tells you that a major number is taken and which name the driver registered it under — it says nothing about minors in use or about how many instances exist. For that, you need the two files below.

/proc/partitions: Live Block Numbering

As covered in the block device lecture, /proc/partitions lists every block device and partition the kernel currently knows about, with its exact major:minor pair and size:

$ cat /proc/partitions
major minor  #blocks  name

   8        0  244190646 sda
   8        1     524288 sda1
   8        2  243665920 sda2
 179        0   15558144 mmcblk0
 179        1     262144 mmcblk0p1

/sys/class: Drivers Organized by Subsystem

Where /proc/devices is a flat registration list, /sys/class presents the same information organized by what kind of device each driver manages, which is usually far more useful when you know what you are looking for but not which major number it uses.

$ ls /sys/class/
block  gpio  hwmon  i2c-dev  input  net  power_supply  tty  ...

$ ls /sys/class/net/
eth0  lo  wlan0

$ ls /sys/class/block/
sda  sda1  sda2  mmcblk0  mmcblk0p1

Each entry under a class directory is a symlink into the real device hierarchy under /sys/devices, and reading files inside it exposes live driver state without ever needing to write a debug print into the driver itself.

$ cat /sys/class/net/eth0/address
02:42:ac:11:00:02

$ cat /sys/class/net/eth0/operstate
up

$ cat /sys/class/block/sda/size
488397168

/sys/dev: Reversing a Major:Minor Pair Back to a Device

If you already have a major:minor pair — say, from ls -l on a device node — and want to find which sysfs device it corresponds to, /sys/dev/char and /sys/dev/block give you a direct reverse lookup, since both are laid out as MAJOR:MINOR symlinks.

$ ls -l /dev/mmcblk0
brw-rw---- 1 root disk 179, 0 Aug 19 09:00 /dev/mmcblk0

$ ls -l /sys/dev/block/179:0
lrwxrwxrwx 1 root root 0 Aug 19 09:00 /sys/dev/block/179:0 -> ../../devices/platform/soc/.../mmcblk0

This is the fastest way to confirm exactly which physical device a number you found elsewhere actually refers to, and it works identically for character devices under /sys/dev/char.

Companion Tools: lsmod, modinfo, dmesg

Three user-space tools round out the picture once you are past the raw /proc and /sys files:

# Which loadable kernel modules are currently resident?
$ lsmod
Module                  Size  Used by
ep_blockdemo           16384  0
ep_netdemo             16384  0

# What does a given module claim to provide/depend on?
$ modinfo ep_blockdemo
filename:       /lib/modules/6.x/extra/ep_blockdemo.ko
license:        GPL
depends:

# What did the driver log during probe/registration?
$ dmesg | grep -i ep_
[ 1234.567] ep_blockdemo: registered with major 253

A Worked Debugging Walkthrough

Suppose a USB storage stick you plugged in never gets a /dev/sdb node, and you want to find out why using only these tools, in order:

Each step narrows the problem to a specific layer: no dmesg entry points at a USB or power problem before the driver is even involved; a registered major with no partition entry points at a probe failure inside the driver; a partition entry with no /dev node points at a udev/device-manager problem rather than a kernel problem at all. This layered approach — kernel log, then registration table, then live numbering, then sysfs — is the same one experienced kernel developers reach for before ever opening driver source.

Comparison of the Key Files

Common Mistakes

• Only checking /proc/devices and assuming a registered major guarantees a working device node — registration and successful probing are two different steps.
• Forgetting that /proc/devices shows nothing about network devices, since they never register a major/minor at all.
• Ignoring dmesg and jumping straight to sysfs, missing an early error that explains everything.
• Confusing a symlink under /sys/class with the real device path — always follow it back to /sys/devices for the authoritative hierarchy.

Best Practices

• Build a habit of checking dmesg, /proc/devices, and the relevant /sys/class directory in that order before suspecting driver source code.
• Use /sys/dev/char/MAJOR:MINOR and /sys/dev/block/MAJOR:MINOR whenever you only have a number and need the real device identity.
• Keep modinfo in your toolkit for confirming exactly which .ko file and version is actually loaded, especially on boards with multiple kernel builds around.

Summary

Once a system is running, /proc/devices, /proc/partitions, and the /sys/class / /sys/dev hierarchies give you a complete, code-free view of every character, block, and (through /sys/class/net) network driver active on the box. Combined with lsmod, modinfo, and dmesg, these files form the standard first line of debugging for any “why isn’t my device showing up” question in embedded Linux development, and they tie together everything covered across this chapter of the free Linux kernel development course.

Frequently Asked Questions