我目前正在开发一个需要大量系统和流程信息的应用程序，其中一些只能通过/ proc获得，而且我有一些关于访问结构的一般性问题。
应用程序将在Linux（kernel＆gt; = 2.6）上运行，而不是在任何其他Unix风格的操作系统上运行。它应该可以访问/ proc中的任何数据，我不能说现在需要什么，因为规范尚不清楚，但整个/ proc目录与应用程序相关。
<小时/> 首先：是否有一个很好的文档，涵盖了从内核版本到内核版本添加/删除的所有功能？我特别好奇的一件事是单个文件的格式。我认为这是理所当然的吗？它在内核版本之间有变化吗？
基于内核连接解析过程根本不会成为问题，只是我找不到任何关于从版本到版本的更改的好文档，这可以帮助我预先捕获解析错误。
另外：是否有一个明确的功能列表可以被内核选项激活/停用（当然/ proc-feature本身除外）？我正在寻找一个只存在于内核中设置的相应选项的文件/目录列表。
作为我正在考虑的一个例子，这是一个指向proc联机帮助页面的链接（http://linux.die.net/man/5/proc），其中包含许多有用的信息，例如：一些选项包括它们可用的最早内核版本，其中一些包括是否需要加载模块。这并没有描述所有信息的输出格式，如果我想解析它，这是我需要的东西（例如，如果它在所有内核版本中都是一致的，或者在某些时候发生了变化）。
我想知道的第二件事是如果被查询的进程在被查询时死亡会发生什么。我的时间间隔是多少？例如，如果我要获取一个读取所有结构的进程列表，并一个接一个地解析它们，如果我的进程x在我读取它之前死了会发生什么？即使我检查目录是否存在，它仍然可以在以后进行一次应用程序调用。
最后但并非最不重要的：那里有没有安装proc的主要发行版吗？
据我所知，许多常用工具都基于/ proc接口，例如lsmod或free，所以我猜我几乎总能想到/ proc存在。
答案 0 :(得分：4)
/proc接口非常稳定（与/sys接口不同），即使没有任何保证。几乎所有的变化都是向后兼容的，至少如果他们已经出现了几个版本。你应该
坚持记录的界面是安全的。如果存在文件，则其格式可以在更高版本中扩展，但通常以向后兼容的方式扩展，例如，向表中添加列。最容易消失的部分是与ACPI或SCSI等硬件系统有关的部分，这些部分正在迁移到/sys（两者都存在较长的过渡期）。
除了硬件信息之外，大多数信息都是独立于架构的（例如/proc/cpuinfo在不同的架构上有非常不同的字段）。
主要文档是内核源代码中的Documentation/filesystems/proc.txt。考虑proc(5)作为概述，proc.txt作为详细信息。内核文档通常是不完整的，所以如果你有时需要求助于阅读源代码，不要感到惊讶。
如果驱动程序的公开数据包含在内核中，则默认情况下会激活/proc的大多数可选部分。例外主要与很少需要从内核外部访问的硬件功能有关;如果您需要访问这些功能，您可能已经预计需要深入挖掘。查看内核源代码中的Kconfig文件以获取详细信息。
过程数据（或与可移动硬件相关的硬件数据或由可卸载模块提供的）可能会在您的鼻子下消失。 /proc下的大多数文件都可以原子方式读取，只需调用一个read个合理大小的缓冲区;如果您按顺序执行多个read调用，则驱动程序应该保证您获得格式良好的数据。没有办法保证读取单独文件之间的原子性;如果你正在阅读有关某个过程的信息，这个过程可能随时死亡，原则上甚至可以在你完成之前用另一个具有相同PID的过程替换。
正如/proc的描述中所述，“每个人都应该在这里说Y”。所有桌面/服务器Linux系统和大多数嵌入式Linux系统必须具有/proc;很多事情，包括ps和其他流程管理命令，许多文件系统和设备相关工具，以及模块加载，都需要它。唯一可以省去/proc的系统是非常小的单用途嵌入式系统，它支持单个硬件配置并运行一组固定的程序。你可以指望它在这里。