6

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.

binW
  • 13,220
  • 11
  • 56
  • 69
  • As sarnold points out objects represented in /dev/ don't have to be "real" devices. If your driver exposes a POSIX type interface (open/read/write) there is not reason not to use it. What sort of communication are you planning on having between user and kernel space? – stsquad Jul 14 '10 at 11:07
  • A part of our software makes too many system calls which is effecting the systems performance. To avoid the burden of these calls we plan to move it into kernel space. Essentially the communication between kernel and user space will involve large data transfers. I would highly appreciate if any one can suggest any other technique for this problem. – binW Jul 14 '10 at 13:02
  • 1
    You're unlikely to find that the system calls are significantly faster from kernel space - at least, not enough so that they outweigh the additional cost of the copying large amounts of data to and from kernel space. That said, investigate a character device file that implements `mmap`. – caf Jul 14 '10 at 13:57

1 Answers1

6

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?)

sarnold
  • 102,305
  • 22
  • 181
  • 238