Procfs is a pseudo, in-memory filesystem: nothing under /proc lives on a physical disk. Every file is generated on demand by kernel code the moment you read it, which is why file sizes often show as zero even though cat happily prints content. Historically it was designed to expose process information — hence the name — but over the years it grew into a general-purpose window into many kernel subsystems, including hardware and driver-specific data.

Modern kernels expect proc entries to use the seq_file interface rather than the old single-page read/write callbacks, because seq_file correctly handles output larger than one memory page. Here is a simplified, original example structured for a 6.x kernel:

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

static int mydrv_proc_show(struct seq_file *m, void *v)
{
    seq_printf(m, "driver_status: active\n");
    return 0;
}

static int mydrv_proc_open(struct inode *inode, struct file *file)
{
    return single_open(file, mydrv_proc_show, NULL);
}

static const struct proc_ops mydrv_proc_ops = {
    .proc_open    = mydrv_proc_open,
    .proc_read    = seq_read,
    .proc_lseek   = seq_lseek,
    .proc_release = single_release,
};

static int __init mydrv_init(void)
{
    proc_create("mydriver", 0444, NULL, &mydrv_proc_ops);
    return 0;
}

Notice the use of struct proc_ops instead of the older struct file_operations for proc entries — this changed in kernel 5.6 and is a common point of confusion when following outdated tutorials.

The kernel community documents procfs, along with sysfs and debugfs, as an ABI whose stability and lifespan are not guaranteed, meaning entries can be renamed, restructured, or removed without the same compatibility promises as system calls. For device drivers specifically, the community has for years steered new code toward sysfs, which enforces a cleaner one-value-per-file convention and integrates properly with the kernel’s device model. Procfs remains appropriate mainly for genuine process and system-wide information, not device-specific driver attributes.

Always set conservative permissions on proc entries with proc_create, and never trust the length or content of data written from user space without validation, since any process with sufficient privilege can write to a writable proc file.

• Procfs is a pseudo-filesystem generated live by kernel code, not stored on disk.
• Use seq_file and struct proc_ops for any modern proc entry.
• New device driver attributes belong in sysfs, not procfs.
• Procfs entries are not a stable ABI and can change between kernel releases.

Q1. What replaced file_operations for proc entries?
Since kernel 5.6, proc entries use struct proc_ops instead of the generic struct file_operations.

Q2. Can I still write drivers that use /proc today?
Technically yes, but the kernel community recommends sysfs for new device attribute interfaces, reserving procfs mainly for process and system information.

Q3. Why does my /proc file show size 0 in ls -l?
Because procfs entries are generated on demand rather than stored, so there is no meaningful static file size to report.

Q4. What is seq_file used for?
Seq_file safely handles proc output that may be larger than a single memory page, iterating and printing data in chunks.

Q5. Is /proc guaranteed to stay the same across kernel versions?
No, the kernel documents /proc as an interface without a formal stability guarantee, so behavior can change between releases.