/proc信息的系统调用接口答案

【问题标题】：System call interface to /proc information/proc信息的系统调用接口
【发布时间】：2026-02-14 04:20:03
【问题描述】：

我可以通过系统调用而不是处理文件中的文本来获取存储在/proc 中的信息吗？

我已经编写了一部分 shell 脚本，但它已经太慢了。我正在考虑用 Perl 重写。

有没有办法从系统调用中获取/proc 信息以进一步加快速度？

【问题讨论】：

我相信/proc 伪文件系统的全部意义在于将许多不同的系统调用或对受保护内核内存的直接访问聚合在一个简单的结构下。
Inotify watch 不能阻止文件系统的卸载。该文档甚至提到了专门的 inotify 事件，该事件在文件系统卸载时被调度：“IN_UNMOUNT - 包含监视对象的文件系统已卸载”。而且，如果您阅读有关该主题的一点点内容，您会发现，专门创建了 inotify/fanotify 来解决其前身 dnotify 的问题，该问题不支持卸载监视目录。
不正确，他们can indeed。
@TomHale 不，他们不能。我的评论中引用的这段话来自Linux manpage of inotify，它明确指出，可以卸载带有 inotify 监视对象的分区。您已链接到 Symantec 文章，该文章提到了 Veritas 文件系统（一种专有的 HP UX 文件系统，不久前移植到 Linux）的一个已知问题。那篇文章承认这个问题是一个错误，并指出缺乏解决方法。 AFAIK，上游 Linux 官方支持的所有文件系统都没有出现此类问题。
我在btrfs 上体验过，显示它发生的记录显示在here。

【解决方案1】：

不，除了open() 和read() 系统调用之外，没有其他与/proc 节点的接口。

请记住，/proc 下的节点不是真实文件。从它们读取的内容将在内核生成内容时尽快返回——备用接口不会更快。

话虽如此，用任何可以直接读取文件的编程语言（如 Perl）重新实现你的 shell 脚本已经可以大大加快它的速度。在 shell 脚本中，每次调用 ls 或 grep 时，您都会启动一个新进程，甚至可能是多个进程。启动过程相对较慢 - 摆脱它可能会解决您的速度问题。

【讨论】：

“替代接口不会更快” - 不同之处在于 proc 中的“文件”是文本流，因此内核必须以文本格式写入数据并且然后应用程序必须将其解析回来，而替代接口可以提供“原始”数据。
@el.pescado：将单个整数转换为字符串并返回很少是瓶颈。打开一个文件要消耗更多（至少，因为它是一个系统调用，而不是一个纯粹的用户空间函数）。但是，正如@duskwuff 所说，/proc 没有其他接口。