为什么linux中使用压缩内核映像？

我在互联网上搜索过这个问题，但找不到任何有用的相关问题，“为什么像bzImage或vmlinuz这样的压缩内核映像被用作初始内核映像”

我能想到的可能解决办法是：

由于内存限制

但最初压缩的内核映像位于硬盘或其他存储介质中，在第二阶段引导加载程序之后的引导期间，内核首先在主内存中解压缩，然后执行

---

所以，当内核在后期要在主内存中解压时，首先需要压缩什么呢。我的意思是，如果主内存可以保存解压后的内核映像，那么内核压缩需要什么呢？

通常，处理器解压的速度比I/O系统读取的速度快。通过减少I/O系统的读取量，可以减少引导所需的时间

当然，这种假设并不适用于所有硬件组合。但它经常这样做

---

嵌入式系统的另一个好处是内核映像在非易失性存储器上占用更少的空间，这可能允许使用更小（更便宜）的闪存芯片。很多人的系统内存约为32MB，闪存只有4MB。

我想，对于嵌入式系统来说，内存限制是最有效的答案，但对于拥有大型存储设备的PC来说，处理器是最好的答案吗？@user2311046：记住，在PC上，加载内核映像必须由引导加载程序使用非常通用的无功能BIOS调用来完成，这也意味着性能非常慢。无DMA、无分散/聚集I/O、无命令队列。EFI使这一点更好，但您仍然希望尽快加载最少的内核，并切换到与I/O控制器的本机通信。由于图像加载速度很慢，传输的图像应该尽可能小，这是通过压缩实现的；您可能希望使恢复内核非常小，以适合于USB记忆棒、很久以前的软盘或CD。最重要的是，

.config

文件意味着您不必这样做。这取决于配置内核的人员，Ben已经给出了有效的理由。自相矛盾的是，您可能不希望在带有就地执行闪存的嵌入式系统中执行此操作。@artlessnoise:安装软盘是一个相当大的挑战，但我从未见过无法安装未压缩图像的USB或CD介质。当然，加载时间仍然非常重要。出于某种原因，我只看到用于引导加载程序的就地执行；不确定Linux内核是否需要在可写内存中以支持自修改代码或其他什么。至少在手臂上支撑。由于大多数代码部分仅标记为

rx

，因此这些部分可能映射到支持

XIP

且无需加载和降低RAM要求的NOR闪存、QuadSPI闪存、ROM等。对于CD或USB，我们的想法是不要为很少需要的救援图像占用太多空间；您可以使用双重用途的存储器。