# Writing an OS Kernel from Scratch – Part 13: sysfs — Exposing Kernel Information as Files
“Kernel runtime state is hidden in registers and memory — how can users view it? Today, we implement sysfs, making CPU, memory, and process information readable like regular files!”
In the previous article, we got standard streams (stdin/stdout/stderr) working in the VFS, and user programs can finally “talk.” But an operating system is not just a platform for running programs — it’s also a manager of system state. Users need to monitor CPU usage, memory usage, process lists, etc.
Linux uses sysfs (/sys) and procfs (/proc) to expose kernel data structures to user space as files. Today, we implement a simplified sysfs, giving your OS “introspection” capability!
🧩 1. What is sysfs? Why Do We Need It?
sysfs is an in-memory virtual file system that:
– Takes no disk space
– Dynamically generates content (computed only when reading files)
– Organized as hierarchical directories (reflecting kernel object relationships)
Typical sysfs paths:
| Path | Content |
|---|---|
| /sys/cpu/0/freq | CPU 0 frequency (Hz) |
| /sys/mem/total | Total physical memory (KB) |
| /sys/kernel/version | Kernel version string |
| /sys/devices/ide/hda/model | Disk model |
💡 Core idea: map kernel data structures to files and directories; users can view system state with cat.
🏗️ 2. sysfs Architecture Design
sysfs is essentially a special file system type registered with the VFS:
Core object: sysfs_dirent
Each file/directory corresponds to a sysfs_dirent:
🔑 The show callback is key: when a user reads the file, the kernel calls it to generate content.
⚙️ 3. Implementing sysfs File Operations
1. sysfs inode creation
2. sysfs file read operation
3. Directory traversal (readdir)
📊 4. Exposing System Information: Implementing Specific Files
1. CPU information
2. Memory information
3. Kernel version
4. Process information (dynamically generated)
🧪 5. Test: User-Space Viewing System Information
Kernel initialization:
User program:
Run results:
✅ Successfully obtained kernel real-time data through the file system interface!
🛠️ 6. Advanced Features (Optional)
1. Writable sysfs files: for runtime configuration (e.g., echo 1 > /sys/debug/enabled). Implement store callback, parse user-written content
2. Symbolic links: for creating aliases (e.g., /sys/cpu/current -> /sys/cpu/0). Add target field in sysfs_dirent
3. Attribute groups: automatically create a group of files for an object (e.g., CPU object automatically has freq/usage/temp). Simplify registration with macros
⚠️ 7. Differences from procfs
| Feature | sysfs | procfs |
|---|---|---|
| Purpose | Export kernel objects (devices, drivers, modules) | Export process information (PID, memory maps, etc.) |
| Organization | By device/driver hierarchy | By PID number |
| Content | One value per file (e.g., freq, model) | Multiple values per file (e.g., status, maps) |
| One-value principle | Strongly enforced: one file, one value | Free format |
✅ In our kernel, sysfs is used for system-level information, procfs for process-level information.
💬 Final Thoughts
sysfs turns the kernel from a black box users can’t touch into a transparent system users can explore. It’s a key component of the OS philosophy “Everything is a file.”
🌟 Making the system transparent is the first step toward making the system trustworthy.
📬 Hands-on challenge: Add a /sys/modules/my_driver/param file to allow runtime configuration of driver parameters. Share your sysfs debugging experience in the comments!
👇 Next article you’d like to see: Interrupt subsystem (IDT + PIC), or process synchronization?
#OS #KernelDevelopment #sysfs #procfs #VirtualFileSystem #KernelInfo #WritingFromScratch
Comments