何时使用 /proc 以及何时使用 /dev
我需要编写一个不是设备驱动程序的内核模块。该模块将与一些用户空间进程进行通信。由于我不想使用 ioctl()，因此我要么在 /proc 目录中创建文件，要么在 /dev 目录中创建设备文件。
问题：我如何在 /proc 和 /dev 之间做出选择。这只是一个判断，还是对于使用这两者有任何不成文的协议。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
将新接口添加到 /proc/ 中将会遇到很大的困难。内核开发人员对它成为各种接口的垃圾场感到不满，除非您实际上通过 /proc/pid/ 修改了有关进程的某些内容，否则我认为您将很难说服内核社区接受它。
/dev/ 中的设备文件可能是可接受的，即使对于不是真正设备驱动程序的模块也是如此。 （例如，/dev/kvm、/dev/pts、/dev/ecryptfs、/dev/fuse、/dev/kmsg、/dev/ptmx 等）但是，设备文件通常更容易使用 ioctl 进行操作（ ），我认为如果可以的话，避免它是正确的。
内核圈当前的趋势是 sysfs 或自定义文件系统。 sysfs 方法基于每个文件单值语义，旨在通过 echo 和 cat 进行操作。如果它对您有用，那么对用户来说那就太好了。自定义文件系统允许您编写非常具体的二进制接口，并且 fs/libfs.c 应该可以帮助您根据自己的需要编写自己的文件系统。 （我不知道有谁使用过 configfs，但我一直认为它看起来很整洁。也许它适合您的模块？）
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?)