# Writing an OS Kernel from Scratch – Part 22: Device Model and devfs — Unified Management of All Hardware Devices
Writing an OS Kernel from Scratch – Part 22: Device Model and devfs — Unified Management of All Hardware Devices
“Your kernel has UART, VGA, IDE, TTY, but they all operate independently with no unified management. Today, we build a device model and implement devfs, so all devices can be discovered and operated like files!”
In previous chapters, we implemented several hardware drivers:
UART (serial port)
VGA (graphics card)
IDE (hard disk)
TTY (terminal)
PIT (timer)
But these drivers are all isolated:
– No unified device registration mechanism
– Users cannot view available devices through /dev
– New drivers require hardcoded paths (e.g., open(“/dev/tty0”))
A real operating system must provide a unified device abstraction and support dynamic device discovery.
Today, we will: ✅ Design a Device Model ✅ Implement devfs (device file system) ✅ Auto-mount /dev and list all devices
Give your OS modern device management capability!
🧩 1. Why Do We Need a Device Model?
Problems with current drivers:
| Problem | Consequence |
|---|---|
| No unified interface | Each driver implements its own open/read |
| Device paths hardcoded | Users must remember /dev/tty0, /dev/hda |
| No dynamic discovery | Adding a device requires modifying kernel code |
Core idea of the device model:
“Everything is an object, every operation is a file”
Device registration: drivers register devices with the kernel during startup
Device class: grouped by type (e.g., tty, block, input)
Device file system (devfs): automatically creates device nodes in /dev
💡 Linux’s sysfs + devtmpfs is based on this idea!
🏗️ 2. Device Model Core Data Structures
1. Device structure (device)
2. Device driver (device_driver)
3. Device number management
🔌 3. Device Registration and Driver Matching
1. Register device
2. TTY device registration example
3. Block device registration example (IDE)
✅ All devices register through a unified interface!
📁 4. Implementing devfs: Device File System
devfs is an in-memory virtual file system that automatically creates device nodes in /dev.
1. devfs superblock and inode
2. Auto-create device nodes
3. Mount devfs
🧪 5. User Space: Accessing Devices Through /dev
1. List all devices
2. Operate on devices (same as before)
3. How does VFS find the device?
open(“/dev/tty0”)
→ VFS looks up dentry
dentry’s inode contains i_rdev = mkdev(4, 0)
VFS calls chrdev_open, finds the TTY driver by major device number 4
The driver’s fops is used for subsequent read/write
🔑 Device numbers are the bridge between VFS and drivers!
🧱 6. Character Device and Block Device Framework
1. Character device registration table
2. Block device registration table
3. Driver registration
🧪 7. Testing and Verification
After mounting devfs:
ls /dev → tty0, tty1, hda, hda1, mouse0, random, null, zero…
✅ devfs shows all registered devices!
echo “hello” > /dev/tty0 → output appears on the terminal screen
cat /dev/random → outputs random numbers
dd if=/dev/hda of=/tmp/backup bs=512 count=1 → reads the first sector of the disk
✅ All devices operate through a unified file interface!
💬 Final Thoughts
The device model and devfs are important components of the operating system abstraction layer. They transform messy hardware details into clean file interfaces, allowing programmers to operate on all devices using the familiar open/read/write/close paradigm.
🌟 The essence of an operating system is to abstract complex hardware into simple interfaces.
📬 Hands-on challenge: Add a null device (/dev/null) and a zero device (/dev/zero), implementing their read/write semantics. Share your device driver registration experience in the comments!
👇 Next article you’d like to see: PCI device enumeration, or Framebuffer graphics driver?
#OS #KernelDevelopment #DeviceModel #devfs #CharacterDevice #BlockDevice #VFS #WritingFromScratch
Comments