Linux kernel 何时使用/proc和何时使用/dev

我需要编写一个不是设备驱动程序的内核模块。该模块将与一些用户空间进程通信。由于我不想使用ioctl（），我只能在/proc目录中创建一个文件，或者在/dev目录中创建一个设备文件

---

问题：我如何在/proc和/dev之间做出决定。这只是一个判断调用，还是在使用这两个方面有任何不成文的协议。

要在/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，但我一直认为它看起来很整洁。也许它适合您的模块？

正如sarnold指出的那样，/dev/中表示的对象不一定是“真实”设备。如果驱动程序公开POSIX类型的接口（打开/读取/写入），则没有理由不使用它。您计划在用户和内核空间之间进行何种通信？我们软件的一部分进行了太多的系统调用，这会影响系统性能。为了避免这些调用的负担，我们计划将其转移到内核空间。本质上，内核和用户空间之间的通信将涉及大型数据传输。如果有人能提出解决这个问题的任何其他技术，我将不胜感激。您不太可能发现从内核空间进行系统调用的速度要快得多-至少，还不足以使它们超过从内核空间复制大量数据的额外成本。也就是说，研究实现

mmap

的字符设备文件。