首页 文章

在Bootpimage的情况下，initrd是否真的减少了内核映像的大小？

提问于
浏览 次
1

根据维基百科关于initrd“ Many Linux distributions ship a single, generic kernel image - one that the distribution's developers intend will boot on as wide a variety of hardware as possible. The device drivers for this generic kernel image are included as loadable modules because statically compiling many drivers into one kernel causes the kernel image to be much larger, perhaps too large to boot on computers with limited memory. This then raises the problem of detecting and loading the modules necessary to mount the root file system at boot time, or for that matter, deducing where or what the root file system is. To avoid having to hardcode handling for so many special cases into the kernel, an initial boot stage with a temporary root file-system — now dubbed early user space — is used. This root file-system can contain user-space helpers which do the hardware detection, module loading and device discovery necessary to get the real root file-system mounted. ”的文章

我的问题是，如果我们添加在initrd中加载实际文件系统所需的模块等而不是在实际内核映像中以节省保存然后我们将在Bootpimage中实现的内容，其中内核和initrd被组合以形成单个bootpimage . 即使使用initrd，这个内核的大小也会增加 .

有人可以澄清吗？

linux linux-kernel arm initrd

2 回答

  • 1

    定义“内核的大小” .

    是的，如果你有一个最小的内核映像加上一个完整的数百个模块的initrd，它可能会比编译所有内容的等效内核占用更多 storage space ，所有模块 Headers 都是如此 . 但是，一旦它启动，加载了几个模块并抛弃所有其余的模块（initrd中的 init ），它将占用相当少的 memory . 另一方面，全内置内核映像一旦启动，仍然在内存和磁盘上一样大，浪费了所有不需要的驱动程序代码的空间 .

    存储几乎总是比RAM更便宜和更丰富，因此在系统运行时以降低可用内存为代价优化存储空间通常会有点愚蠢 . 即使对于网络启动，为了更快的启动而牺牲总图像大小的运行时功能也没什么意义 . 这些考虑可能具有任何优点的少数系统几乎肯定不会首先使用通用多平台内核 .

    回复于
  • 2

    size 有几个方面，这可能令人困惑 .

    • 磁盘/网络上的二进制大小

    • 启动时间大小

    • 运行时间大小

    TL-DR;使用initrd with modules为通用映像提供了当前（3.17）Linux内核代码的最小内存占用量 .

    我的问题是，如果我们添加在initrd中加载实际文件系统所需的模块等而不是在实际内核映像中以保存保存然后我们将在Bootpimage中实现的内容，其中内核和initrd被组合以形成单个bootpimage . 即使使用initrd，这个内核的大小也会增加 .

    你是正确的，无论你选择哪种机制，都会传输相同数量的数据 . 实际上，带有模块加载的initrd将比完全静态链接的内核大，启动时间会更慢 . 听起来不错 .

    专门为设备构建的定制内核并不包含额外的硬件驱动程序或模块支持始终是最好的 . Debian handbook on kernel compilation给出了一个用户可能想要制作自定义内核的两个原因 .

    • 通过功能最小化限制安全问题的风险 .

    • 优化内存消耗

    第二种选择通常是最关键的参数 . 最小化正在运行的内核消耗的内存量 . initrd （或 initramfs ）是一个二进制磁盘映像，作为ram磁盘加载 . 所有用户代码都具有探测设备和使用 module loading 来获取系统正确驱动程序的单一任务 . 完成此作业后，它将安装一个真正的启动设备或正常的 root 文件系统 . 发生这种情况时，将丢弃 initrd 图像 .

    initrd 不消耗运行时内存 . 您将获得一个通用图像和一个具有相当小的 run time 足迹的图像 .

    我要说的是，发行人的努力有时会产生性能问题 . 通常，ARM驱动程序仅针对 one SOC进行编译;虽然源支持SOC系列，但只能通过条件选择一个 . 在最近的内核中，ARM驱动程序始终支持整个SOC系列 . 内存开销很小 . 但是，将函数指针用于低级驱动程序传递函数可能会限制控制器的带宽 .

    cacheflush例程有一个多缓存选项 . 函数指针会导致编译器自动溢出 . 但是，如果编译特定的缓存类型，编译器可以内联函数 . 这通常会产生更好更小的代码 . 大多数司机没有这种类型的基础设施 . 但是，如果编译为CPU调整的单片内核，则会有更好的运行时行为 . 几个关键的内核函数将使用内联函数 .

    编译到内核时，驱动程序通常不会更快 . 许多系统通过USB，PCMCIA，SDIO等支持热插拔 . 这些系统在模块加载方面也具有内存优势 .

    回复于

相关问题