原文：ioremap() and memremap() [LWN.net]
下面翻译自google：
像用户空间一样，内核通过页表访问内存。因此，当内核代码需要访问内存映射的I / O设备时，必须首先设置适当的内核页面表映射。长期以来，用于该工作的内核工具是ioremap（），它具有许多变体。事实证明，其中一些变体并非总是适合此工作的工具，从而导致内核中存在一定数量的变通方法。但是，这种情况可能会发生变化，这是针对有问题的情况而从ioremap（）移开的一部分 。
成功调用ioremap（）会返回与请求的物理地址范围的开始相对应的内核虚拟地址。但是，出于多种（通常是特定于体系结构的）原因，通常不打算直接取消引用此地址。相反，应使用诸如readb（）或iowrite32（）之类的访问器函数 。为了强制执行此规则，使用__iomem标记注释了 ioremap（）的返回地址。这将导致稀疏检查器抱怨没有使用适当功能的访问。
缓存也无关紧要。CPU通常从内存中缓存数据，但是当出于多种原因而涉及I / O时，这是一个坏主意。尝试从I / O存储器读取完整的缓存行不会带来意料之外的副作用，并且延迟对I / O存储器的写操作可能会更改设备的运行方式。I / O存储器通常应作为设备的直接控制通道；为此，ioremap（） 至少在x86体系结构上禁用了对设备内存的缓存。
实际上，从ioremap（）获得的内存范围的缓存状态 尚未完全定义。通常，未缓存是默认设置，但是仍然存在一个ioremap_nocache（），可以通过代码来调用该代码，该代码需要绝对确保在它与其设备内存之间没有缓存。
但是，在某些情况下，I / O内存只是内存。图形适配器使用的视频内存就是一个典型的例子。使用这种内存，可以预期直接指针引用可以工作，并且可以在CPU中进行缓存；实际上，可能需要获得合理的性能。对于这种情况，如果可能，有一个ioremap_cache（）创建缓存的映射。大多数体系结构还具有几个变体，它们允许缓存读取，但限制写入缓存。特别地，ioremap_wc（）允许组合写操作，而ioremap_wt（）导致写操作直接进入设备内存。通过这些变体，驱动程序编写者可以获得特定的设备内存所需的映射类型。
不过，丹·威廉姆斯（Dan Williams）最近在使用这一系列功能时遇到了一些问题。一种是它们都返回带有__iomem批注的指针 。几乎可以肯定的是，在启用了缓存的情况下映射I / O内存的驱动程序将把结果地址范围视为普通内存，包括直接将指针解引用到该范围。为此，他们必须放弃__iomem 批注或直接忽略它。在前一种情况下，代码比其他情况要嘈杂；在后一种情况下，任何在代码上运行稀疏的人 都将忽略所产生的警告。
除此之外，许多体系结构不支持所有各种缓存模式，因此特定于体系结构的头文件充满了以下行：
#define ioremap_wt ioremap_nocache
结果是像ioremap_wt（）之类的函数的调用者可能无声地无法获得他们所要求的直写式缓存。
Dan对这两个问题的答案都是一个补丁集，该补丁集添加了一个新功能来映射设备内存，其行为类似于内存：
void *memremap(resource_size_t offset, size_t size, unsigned long flags);
此函数将iomem_resource 重新映射为可缓存内存,（成功）返回一个地址，该地址映射到在给定物理偏移量和给定 大小（以字节为单位）上找到的设备内存。该标志参数可以是 MEMREMAP_WB全回写缓存或MEMREMAP_WT为写式高速缓存。返回的地址没有 __iomem批注。如果无法提供请求的缓存行为，则memremap（）将返回NULL而不是退回到其他类型的缓存。
补丁集将大多数内核代码转换为新接口。
在撰写本文时，这项工作是在其第三修订版中，并且已经解决了所提出的（很少）评论意见。它阐明了驱动程序API，清楚地将两个不同的用例分隔开来映射设备内存，并且它应导致较少的稀疏警告噪声。在这一点上，没有太多不喜欢的东西，因此将其排除在4.3合并窗口之外应该没有太多。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/214138.html原文链接：https://javaforall.net
![Dynamics Crm 2011 Or 2013 IFD 部署一段时间后，CA验证问题[通俗易懂]](https://javaforall.net/wp-content/uploads/2020/11/2020110817443450-480x300.jpg)
