procfs如何输出/proc/iomem？

我已经在这个网站上研究了类似的问题（在最后列出），但仍然觉得遗漏了几点，希望有人能在这里提供帮助：

proc

文件系统中是否有一个钩子将

/proc/iomem

inode

连接到转储信息的函数？我无法找到这个函数在proc fs中的位置。我在linux源代码树

fs/proc

下为

iomem

做了一个

grep

，什么都没有得到。所以，也许这更像是一个

procfs

问题。。。这个问题的答案可能有助于我找到下一个问题的答案

/proc/iomem

比我从

dmesg

或

/sys/firmware/memmap

中提取的BIOS E820信息有更多的条目（这两者实际上是一致的）。例如，

/sys/firmware/memmap

似乎没有pci内存映射区域。驱动程序的init代码调用

request\u mem\u region（）

并向映射添加更多信息，因此在某个地方应该有一个全局变量（所有资源的根？）

关于stackoverflow的问题，我已经研究过：

struct-resource-iomem\u-resource

是您要查找的，它在

kernel/resource.c

中定义和初始化（通过

proc\u-create\u-seq\u-data（）

）。在同一个文件中，实例

struct seq_operations resource_op

定义了当您（例如

cat

从userland创建文件时）发生的情况

iomem\u资源

是一个全局导出的符号，在整个内核（包括驱动程序）中用于请求资源。您可以找到分散在

devm\u/request\u resource（）

内核中的实例，这些实例基于固定设置或配置获取

iomem\u资源或其同级
ioport\u资源。采用配置的方法的示例包括a）嵌入式设置中流行的设备树，以及b）E820或UEFI，可以在x86上找到更多

从问题中提出的b）开始，文件

arch/x86/kernel/e820.c

显示了如何通过

insert_resource（）

将保留内存插入

/proc/iomem

。 这篇文章详细介绍了从BIOS请求内存映射细节的动态过程

设备驱动程序如何请求所需资源的另一个备选顺序（取决于的

配置）是：

Open Firmware API正在遍历设备树，并找到匹配的驱动程序。例如，通过\u设备\u id的
结构

驱动程序定义了一个
struct platform\u device
，其中包含
struct\u device\u id
和探测函数。这个探测函数就是这样调用的
在probe函数内部，调用
platform\u get\u resource（）
，从设备树中读取
reg
属性。此属性定义特定设备的物理内存映射
调用
devm\u request\u mem\u region（）

看起来它在
kernel/resource.c
中。OF对于x86来说并不典型，而且，看看前面提到的E820，我认为这就是OP.@0andriy OF的例子，这就是我所说的典型。
iomem\u资源
变量——这是OP第二个问题的答案——适用于是否使用OF或e820探测驱动程序。无论如何，我将修改答案，使其不那么模棱两可。谢谢各位，这几乎解决了我所有的问题，除了这一部分-如果E820输出不包括PCI mmap区域，那么这意味着当内核接管时，PCI mmap还没有设置？如果是这样，那么request_resource（）必须有一些低级代码来设置hostbridge寄存器，以便pci设备请求的未来地址可以转发到pci桥。但我没有在request_resource（）中找到这段代码。（太长了，必须分成两个回复）。另一个猜测是，BIOS在将控制权交给内核之前，确实为所有可能的未来pci请求保留了巨大的空间，但它只是不通过E820报告，内核不知怎么地通过其他方式将其挖掘出来？这样，至少request_resource（）不需要调整主机桥寄存器，因为设备只是从更大的区域内请求一个子区域，而更大的区域已经完全映射/转发到pci桥。这有意义吗？@QnA，PCI是自我发现总线，您所说的隐藏在drivers/PCI/setup-res.c下。此外，对于基于PCI-ACPI的平台，根据PCI固件规范，信息通过MCFG表传播。