How to define inode_operation for proc_dir_entry?

788 views Asked by At

I'm trying to learn how to write linux kernel module using The Linux Kernel Module Programming Guide

However I realized that the examples in this book are quite obsolete. Following is one of the examples from the book.

static struct proc_dir_entry *Our_Proc_File;
static int module_permission(struct inode *inode, int op, struct nameidata *nd)
{

    if (op == 4 || (op == 2 && current−>euid == 0))
            return 0;
    return −EACCES;
}
static struct inode_operations Inode_Ops_4_Our_Proc_File = {
    .permission = module_permission
}
static struct file_operations File_Ops_4_Our_Proc_File = {
    // ... 
};

int init_module()
{
    Our_Proc_File = create_proc_entry(PROC_ENTRY_FILENAME, 0644, NULL);
    // above line should use proc_create() 
    if (Our_Proc_File == NULL) {
            remove_proc_entry(PROC_ENTRY_FILENAME, &proc_root);
            return −ENOMEM;
    }

    Our_Proc_File−>owner = THIS_MODULE;
    Our_Proc_File−>proc_iops = &Inode_Ops_4_Our_Proc_File;
    Our_Proc_File−>proc_fops = &File_Ops_4_Our_Proc_File;
}

When I looked through the source code, I found that proc_iops was being removed from the proc_dir_entry structure in Linux 4.x

So How should I define the inode_operations for the proc_dir_entry

1

There are 1 answers

0
Tsyvarev On BEST ANSWER

General purpose of /proc filesystem is to give kernel and its modules ability to easily create files with "content" generated on the fly and directories for group these files. One may do that by using proc_create() and friends.

As for inodes and dentries, they are part of filesystem's internals: it is better to not modify them and their operations.

Actually, file_operations are powerful by themselves. If you find mode parameter for proc_create() insufficient to reflect access rights, you may check access in .open() file operation.


As for the field proc_iops in struct proc_dir_entry, it is still exist. But the structure itself is defined in internal header fs/proc/internal.h - another signal, that accessing its fields from outside is not expected.