为什么模块从地址0xbf000000开始
我使用 insmod hello.ko 启动我构建的模块。并使用lsmod来查找这个模块。然后我发现了一个奇怪的问题，我看到该模块从地址0xbf000000开始。据我所知，内核地址是从0xc0000000开始的，驱动模块是内核的一部分。但它的地址在用户空间。这很奇怪。
顺便说一句，它是在 ARM 平台上。
i use insmod hello.ko to launched the module which i build. and use the lsmod to look up this module.Then i found a strange issue, i saw the module start from address 0xbf000000. As i known, the kernel address start from 0xc0000000, the driver module is a part of the kernel.But its address is in the user space.This`s quit odd.
BTW it`s on the ARM platform .
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
所有内核代码都驻留在虚拟地址 0xc0000000 的方案实际上仅限于 x86，甚至仅在使用用户空间和内核之间 3:1 内存地址分割的默认配置选项时才有效。
在 Arm 上，虚拟内存空间寻址方案有所不同，内核可加载模块从常量 TASK_SIZE 映射到 PAGE_OFFSET-1，其中 PAGE_OFFSET 是物理内存直接 1:1 映射开始的地址。
有关 Arm 中内容的完整说明，请参阅此文档：http:// www.arm.linux.org.uk/developer/memory.txt
它也位于 Linux 内核的 Documentation 目录中的 Arm 子目录下，这是寻找此类问题答案的好地方对于其他架构:-)
The scheme under which all kernel code resides at virtual address 0xc0000000 is actually only limited to x86 and even there only when using the default config option of 3:1 memory address split between user space and kernel.
On Arm, the virtual memory space addressing scheme is different and kernel loadable modules are mapped from the constants TASK_SIZE to PAGE_OFFSET-1, where PAGE_OFFSET is the address where a direct 1:1 mapping of physical memory begins.
For a full accord of what goes where in Arm, see this document: http://www.arm.linux.org.uk/developer/memory.txt
It also resides somewhere in the Documentation directory of the Linux kernel under the Arm sub-directory, which is a good place to look for answers for such questions for other architectures :-)