Miss sample about inode_operations in `procfs3.c`

[chenk008]

In sectionManage /proc file with standard filesystem, there is some description about inode_operations, but the sample procfs3.c don't contains code about it.

[stlaz]

I found the original example including inode_operations in lkmpg for kernels 2.4.* here: https://tldp.org/LDP/lkmpg/2.4/html/lkmpg.html#AEN770

edit: also, the struct inode_operations seems to be documented here if anyone's looking for it - https://www.kernel.org/doc/html/latest/filesystems/vfs.html#struct-inode-operations

[jserv]

I found the original example including inode_operations in lkmpg for kernels 2.4.* here: https://tldp.org/LDP/lkmpg/2.4/html/lkmpg.html#AEN770

Thank @stlaz for the information. Can you submit a pull request for the missing LKM code?

[jcjgraf]

I looked into this issue a bit and started to update the example from kernel version 2.4. A lot has changed since then, and the way the proc is create was revised multiple times. Back in the days you would pass a struct proc_dir_entry * to the proc creation function (proc_register). But with today's interface, you pass a struct proc_ops * and get the struct proc_dir_entry from the creation function (proc_create). As with kernel version 2.4, struct proc_dir_entry still contains const struct inode_operations *proc_iops, however, it is not directly exposed via some interface. So, to change the inode operation, you would have to do something like:

our_proc_file = proc_create(PROCFS_NAME, 0644, NULL, &proc_file_fops);
our_proc_file->proc_iops->permission = our_permission;

I do not know how save this method is, or whether changing proc_iops could break anything.

I think in general, section 7 The /proc File System could need some improvements. I find it rather hard to follow. Especially since it tries introduce all the different ways on how to manage the proc. Namely using file operations, inode operations, proc operations, and the seq_file. I i feel that the explanations of the first three methods is pretty mixed up. For example, in the code examples you have static struct proc_ops file_ops_4_our_proc_file. So, you are naming the proc operations file operations, even though file operations and proc operations are something different. Also, you are saying:

Because we don’t get called when the file is opened or closed, there’s nowhere for us to put try_module_get and module_put in this module, and if the file is opened and then the module is removed, there’s no way to avoid the consequences.

This is followed by example procfs2 and procfs3, which indeed to not utilize a open/release function. But then example procfs3 comes, which suddenly utilizes proc_open/proc_release, without any further explanations. You got me pretty confused there 😮‍💨

If there is interest I am willing to help with the updating