Menu
I need to write a kernel module that is not a device driver. That module will be communicating with some user space processes. As I dont want to use ioctl(), I am left with either creating a file in /proc directory or creating a device file in /dev directory.
Question: How do i decide between /proc and /dev. Is this just a judgement call or are there any unwritten agreements on using these two.
256
Why do we have /proc? Because it's useful. And convenient. It's both of those things to users (so they can just write a sh/awk/perl/whatever script to read a particular "file", rather than spend ages figuring out how to do a syscall , or query it from their interactive shell) AND to many command-line tools.
/proc is very special in that it is also a virtual filesystem. It's sometimes referred to as a process information pseudo-file system. It doesn't contain 'real' files but runtime system information (e.g. system memory, devices mounted, hardware configuration, etc).
/proc and /dev provide file-based interfaces to. the internals of Linux. They assist in determining the configuration. and state of various devices and processes on a system.
The /proc/ directory — also called the proc file system — contains a hierarchy of special files which represent the current state of the kernel — allowing applications and users to peer into the kernel's view of the system.
You will have a great deal of difficulty getting a new interface added into /proc/. The kernel developers are unhappy that it has become a dumping ground for miscellaneous interfaces, and unless you are actually modifying something about processes via /proc/pid/, I think you'll have trouble convincing the kernel community to accept it.
A device file in /dev/ may be acceptable, even for modules that aren't really device drivers. (e.g., /dev/kvm, /dev/pts, /dev/ecryptfs, /dev/fuse, /dev/kmsg, /dev/ptmx, etc.) However, device files are too-often easier to manipulate with ioctl(), and I think you're right to avoid it if you can.
The current trend in kernel circles is sysfs or custom filesystems. The sysfs approach is based upon single-value-per-file semantics, intended to be manipulated with echo and cat. It's wonderful for users if it works for you. Custom filesystems lets you write very specific binary-capable interfaces, and fs/libfs.c should help you write your own filesystem to your own needs. (I don't know anyone who has used configfs, but I've always thought it looked neat. Maybe it would suit your module?)
65
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
