访问/proc

发布于 2024-12-05 01:34:54 字数 1096 浏览 0 评论 0原文

我目前正在开发一个需要大量系统和进程信息的应用程序，其中一些信息只能通过 /proc 获得，并且我有一些关于访问结构的一般问题。

该应用程序将在 Linux（内核 >= 2.6）上运行，而不是在任何其他 Unix 风格的操作系统上运行。它应该可以访问 /proc 中的任何数据，我不能说现在需要什么，因为规范尚不清楚，但整个 /proc 目录与应用程序相关。

First of all: Is there a good documentation which covers all the features added / removed from kernel version to kernel version? One thing I'm curious about in particular is the format of the individual files. Can I take that for granted? Does it change among kernel versions?

连接基于内核的解析过程根本不是问题，只是我找不到任何关于版本之间的变化的好的文档，这可以帮助我提前捕获解析错误。

此外：是否有可以通过内核选项激活/停用的功能的明确列表（当然 /proc-feature 本身除外）？我正在寻找仅在内核中设置了适当选项的情况下才存在的文件/目录列表。

作为我正在考虑的一个例子，这是 proc 手册页 (http://linux.die.net/man/5/proc) 的链接，其中包含很多好的信息，例如一些选项包括最早的选项它们可用的内核版本，其中一些包括是否需要加载模块。但这并没有描述所有信息的输出格式，如果我想解析它，这是我需要的（例如，如果它在所有内核版本中保持一致或在某个时刻发生更改）。

我想知道的第二件事是如果查询的进程在查询时死亡会发生什么。我的时间间隔是多少？例如，如果我要获取读取所有结构的进程列表，并逐个解析它们，如果我的进程 x 在我读取它之前就死掉了，会发生什么？即使我检查该目录是否存在，它仍然可能在一次应用程序调用后消失。

最后但并非最不重要的一点是：是否有任何主要发行版不安装进程？

据我了解，很多常用工具都是基于 /proc 接口的，例如 lsmod 或 free ，所以我猜我可以期望 /proc 存在几乎总是如此。

原文

I'm currently developing an application which needs a lot of system and process information, some of which is only available through /proc, and I have some general questions about accessing the structures.

The application will be run on Linux (kernel >= 2.6), not on any other Unix-flavored OS. It should have access to any data in /proc, I can't say what is necessary now as the specifications are not clear yet, but the whole /proc directory is relevant to the application.

Hooking up the parsing process based on the kernel wouldn't be a problem at all, it's just that I couldn't find any good docs on what has changed from version to version which could help me catching parsing errors in beforehand.

In addition: Is there a definite list of features that can be activated / deactivated by kernel options (except of course the /proc-feature itself)? I'm looking for a list of files / directories that only exist with the appropriate options being set in the kernel.

As an example of what I'm thinking of, this is a link to the proc manpage (http://linux.die.net/man/5/proc) which includes a lot of good information, e.g. some options include the earliest kernel version they were available at, some include whether a module is necessary to be loaded. This does not describe the output format of all information though, which is something I need if I want to parse it (e.g. if it is consistent throughout all kernel versions or changed at some point).

The second thing I'm wondering about is what happens if the process queried dies while being queried. What is my time interval? For example if I'm going to fetch a list of processes reading all the structures, and parse them one after another, what happens if my process x dies before I get to read it? Even if I check if the directory exists, it could still be gone one application call later.

Last but not least: Is there any major distribution out there that is not mounting proc?

From what I understand, a lot of common tools are based on the /proc interface such as lsmod or free, so I'm guessing that I can expect /proc to exist almost always.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

忱杏 2024-12-12 01:34:54

/proc 接口非常稳定（与 /sys 接口不同），即使没有任何保证。几乎所有更改都是向后兼容的，至少如果它们已经存在了几个版本的话。你应该
为了安全起见，请遵循记录的接口。如果文件存在，则其格式可以在以后的版本中扩展，但通常以向后兼容的方式扩展，例如向表中添加列。最有可能消失的部分是与硬件系统相关的部分，例如 ACPI 或 SCSI，它们正在迁移到 /sys（两者都存在时，过渡期很长）。

大多数信息都是与体系结构无关的，除了硬件信息（例如/proc/cpuinfo在不同的体系结构上有非常不同的字段）。

主要文档是 Documentation/filesystems/proc.txt< /a> 在内核源代码中。考虑 proc(5)< /a> 作为概述，proc.txt 作为详细信息。内核文档通常不完整，因此如果您有时需要阅读源代码，请不要感到惊讶。

如果其公开的数据驱动程序包含在内核中，则默认情况下会激活 /proc 的大多数可选部分。这些异常大多与很少需要从内核外部访问的硬件功能有关；如果您需要访问这些功能，您可能已经期望需要更深入地挖掘。查看内核源代码中的 Kconfig 文件以获取详细信息。

过程数据（或与可移动硬件相关或由可卸载模块提供的硬件数据）可能会在您眼皮子底下消失。 /proc 下的大多数文件都可以通过具有合理大小的缓冲区的单个 read 调用以原子方式读取；如果您按顺序执行多个read调用，驱动程序应该保证您获得格式正确的数据。无法保证读取单独文件之间的原子性；如果您正在阅读有关某个进程的信息，则该进程可能随时终止，原则上甚至可能在您完成之前被具有相同 PID 的另一个进程替换。

正如 /proc 的描述中所说，“这里每个人都应该说 Y”。所有桌面/服务器Linux系统和大多数嵌入式Linux系统都必须有/proc；很多东西，包括 ps 和其他进程管理命令、许多文件系统和设备相关工具以及模块加载，都需要它。唯一能够免除 /proc 的系统是非常小的单一用途嵌入式系统，它们支持单一硬件配置并运行一组固定的程序。您可以信赖它就在这里。

The /proc interfaces are pretty stable (unlike the /sys interfaces), even if nothing is guaranteed. Almost all changes are backwards compatible, at least if they've been around for a few versions. You should
stick to the documented interfaces to be safe. If a file exists, its format may be extended in later versions, but normally in a backwards compatible way, e.g. adding columns to a table. The parts that are most at risk of disappearing are parts concerning hardware susbystems such as ACPI or SCSI, which are migrating to /sys (with a long transition period when both exist).

Most of the information is architecture-independent, except for hardware information (e.g. /proc/cpuinfo has very different fields on different architectures).

The main documentation is Documentation/filesystems/proc.txt in the kernel source. Consider proc(5) to be the overview and proc.txt to be the fine details. The kernel documentation is often incomplete, so don't be surprised if you need to resort to reading the source sometimes.

Most optional parts of /proc are activated by default if the driver whose data it exposes is included in the kernel. The exceptions are mostly related to hardware features that rarely need to be accessed from outside the kernel; if you need to access these features, you're probably already expecting to need to dig deeper. Look through Kconfig files in the kernel source for detailed information.

Process data (or hardware data related to removable hardware or provided by unloadable modules) can disappear under your nose. Most files under /proc can be read atomically, with a single read call with a reasonably-sized buffer; if you perform multiple read calls in sequence, drivers are supposed to guarantee that you get well-formed data. There is no way to guarantee atomicity between reads of separate files; if you're reading information about a process, this process can die at any time, and in principle could even be replaced by another process with the same PID before you're finished.

As it says in the description of /proc, “everyone should say Y here”. All desktop/server Linux systems and most embedded Linux systems must have /proc; a lot of things, including ps and other process management commands, many filesystem and device-related tools, and module loading, require it. The only systems that might be able to dispense with /proc are very small single-purpose embedded systems that support a single hardware configuration and run a fixed set of programs. You can count on its being here.

回复收藏 0 原文

~没有更多了~