How the kernel talks to hardware: character vs block vs network devices, major/minor & /dev, the device model (bus→device→driver, probe, hotplug) via sysfs & udev, and how a driver moves data — MMIO registers, interrupts, and DMA — plus the character-driver file_operations/ioctl interface.
How the kernel talks to hardware — the device model, the three device classes, and how a driver actually moves data (registers, interrupts, DMA). Original, interview-focused notes.
Devices are exposed as files under/devand organized by the device model under/sys. A driver binds to a device on a bus, registers a set of operations, and moves data via memory-mapped registers + interrupts + DMA.
| Class | Access | Examples |
|---|---|---|
| Character | Byte stream, no seek buffering — read/write directly | tty, serial, /dev/null, input |
| Block | Fixed-size blocks, random access, via the page cache & block layer | Disks, SSDs, NVMe — see Block Devices |
| Network | Not a /dev file — packets via the socket/net stack | NICs (eth0) |
Each device node has a major number (which driver) and minor (which instance).
ls -l /dev shows c/b and the major,minor.
/sys. A driver registers with its bus; when a matching device appears, the bus calls
the driver's probe() to bind them — that's hotplug./dev nodes, applies naming rules (persistent NIC/disk names), and runs actions on plug/unplug.modprobe); lsmod/modinfo
inspect them.ioremap) or legacy port I/O. The driver reads status / writes commands here.The efficient pattern: DMA moves the bytes, one interrupt signals completion, a bottom half processes the result — minimal CPU per byte. PIO (CPU copies each word) is only for tiny/slow devices.
A char driver registers file_operations (open, read, write,
ioctl, mmap) so its /dev node behaves like a file. ioctl
is the catch-all for device-specific control that doesn't fit read/write.
/dev node and a stable name? (uevent → udev rules)probe(); hotplug)ioctl for?