← Previous Lecture  |  Next Lecture →

What You Will Learn

• How proc_symlink() creates soft links inside the /proc tree
• How proc_create_single_data() reduces boilerplate for read-only proc files
• Why the classic file_operations approach was replaced by proc_ops from kernel 5.6 onward
• Which real in-tree drivers still rely on these APIs today
• Why procfs is discouraged for new driver interfaces on modern kernels

Prerequisites

• A working loadable kernel module (LKM) build environment (kernel headers + make)
• Basic familiarity with creating a /proc directory and a simple proc file
• Comfort reading C structures and function pointers

A Quick Recap: Why procfs Exists

procfs began life as a way to expose kernel and process information as plain text files that any user-space tool could read with cat. Over time, driver authors started (mis)using it as a general-purpose communication channel between user space and their modules. The kernel community now treats this as legacy behavior — still supported, but not recommended for anything except process- or subsystem-wide statistics.

Creating Soft Links with proc_symlink()

Just like a regular filesystem, the virtual /proc tree supports symbolic links. The kernel exposes this through a dedicated helper that creates a soft link entry pointing at another path inside /proc, without requiring you to write any read or write callback at all — the VFS layer resolves the link the same way it resolves any other symlink.

This is useful when you want to expose the same information under two different, more discoverable paths without duplicating your callback code. A good real-world parallel is how /proc/self itself is implemented as a dynamic symlink resolved per-process.

The Shortcut API: proc_create_single_data()

Most proc files only need to support reading — a user runs cat and gets some formatted text back. Writing a full proc_ops structure just to register a single show callback is unnecessary overhead. The “single data” family of helpers exists exactly for this case: you hand the kernel a function pointer that fills a seq_file buffer, plus an optional private data pointer, and the kernel wires up everything else for you.

Modern Signature (Kernel 6.x)

One important update from the older textbooks: starting with kernel 5.6, procfs stopped using the generic struct file_operations for its internal dispatch table and switched to a dedicated, smaller struct proc_ops. This was done to shrink the per-file memory footprint and to prevent proc code from accidentally depending on VFS-only fields. If you are following an older book or blog that still shows file_operations being passed around for procfs, that code will not compile cleanly on a current 6.x kernel — conceptually the idea is identical, only the struct name and a few field names changed.

#include <linux/proc_fs.h>
#include <linux/seq_file.h>

static int mydrv_status_show(struct seq_file *m, void *v)
{
    int *priv = m->private;

    seq_printf(m, "mydrv: status=%d\n", priv ? *priv : -1);
    return 0;
}

static int __init mydrv_proc_init(void)
{
    struct proc_dir_entry *dir;

    dir = proc_mkdir("mydrv", NULL);
    if (!dir)
        return -ENOMEM;

    proc_create_single_data("status", 0444, dir,
                             mydrv_status_show, NULL);
    return 0;
}

Notice there is no separate open()/release() pair to write — the helper internally wraps your show function with the standard seq_file plumbing.

The Private Data Parameter

The last argument to proc_create_single_data() is stashed on the resulting seq_file as its private member. This lets one generic show function serve several proc files that each report on a different device or counter, simply by passing a different pointer at registration time.

Who Actually Uses This in the Mainline Kernel Today

Architecture: Where This Fits in the I/O Path

Real-World Use Case

A common scenario is a driver that wants to expose a single read-only counter, such as an interrupt count or a firmware version string, without going through the trouble of a full character device. proc_create_single_data() keeps that use case to under fifteen lines of code, which is why several in-tree drivers still rely on it for optional debug output even on kernels released in 2026.

Common Mistakes and Troubleshooting

Best Practices

• Prefer proc_create_single_data() over a full proc_ops struct whenever the file is read-only
• Keep proc output plain text and stable in format — scripts often parse it
• Always pair every creation call with a matching removal call in your module’s exit path
• Reserve procfs strictly for process/subsystem statistics; use sysfs for device attributes (next lecture)

Performance Considerations

procfs reads are synchronous and run in process context, so keep your show() callback fast and non-blocking. Avoid taking long-held locks or performing hardware I/O directly inside the callback; snapshot the data first if it involves anything slow.

Security Considerations

Always set the narrowest permission mode that satisfies your use case — 0444 for read-only status files is usually correct. Never trust or execute data placed in a proc file’s private pointer, and never expose kernel pointers directly in proc output; modern kernels hash pointers printed via %p for this exact reason.

Summary / Key Takeaways

• proc_symlink() creates a soft link inside /proc with zero callback code
• proc_create_single_data() is the fastest way to expose a read-only proc file
• Since kernel 5.6, procfs internally uses struct proc_ops, not file_operations
• procfs remains fine for statistics but is not the recommended interface for new device drivers

Conclusion

The miscellaneous procfs helpers covered in this lesson round out your understanding of the procfs API in Linux kernel programming, and knowing the kernel 5.6 proc_ops transition will save you real debugging time when working against a current 6.x tree. In the next lecture of this free Linux kernel programming course, we move to sysfs — the interface the kernel community actually recommends for device drivers.

Frequently Asked Questions

Q1. Is procfs deprecated in the Linux kernel?

No. procfs is actively maintained and widely used for process and subsystem statistics. What is discouraged is using it as a general-purpose driver communication channel for new drivers.

Q2. What changed with proc_ops in kernel 5.6?

procfs internal dispatch moved from the generic struct file_operations to a dedicated, smaller struct proc_ops, reducing memory usage and decoupling procfs from unrelated VFS fields.

Q3. Do I need a proc_ops structure for proc_create_single_data()?

No. That is exactly what makes this helper convenient — it only needs your show callback and an optional private data pointer.

Q4. Can proc_create_single_data() support writes?

No, it is designed for read-only files. If you need write support, you must register a full proc_ops structure with a write handler.

Q5. Should new drivers use procfs or sysfs?

Use sysfs for device attributes. procfs should be reserved for statistics-style, non-device data.

Q6. Is proc_symlink() commonly used in real drivers?

It is used sparingly, mostly to provide a more discoverable alias path to an existing proc entry rather than as a primary interface.

Q7. What happens if I forget to remove proc entries on unload?

Stale entries can cause crashes or errors if user space accesses them after your module is unloaded; always clean up in your exit function.

← Previous Lecture  |  Next Lecture →