将内核模块编译到内核中（而不是作为可加载模块）有什么好处？
答案1
这取决于。如果您的内存量较小，则使用模块可能会改善简历，因为它们不会每次都重新加载（我发现它在 2 GiB RAM 上很重要，但在传统硬盘上的 4 GiB 上则不然）。当由于电池模块中的某些错误（无论是编译还是作为模块）而导致启动时间很长（几分钟）时尤其如此。即使 gentoo 上没有错误，我也设法将时间（由 报告systemd-analysis）从 33 秒缩短到 18 秒，只需从静态编译内核更改为模块 - “令人惊讶”的是，内核的启动时间从 9 秒更改为 1.5 秒。
此外，当您不知道要使用什么硬件时，模块显然是有用的。
附言。只要将重要的驱动程序包含在 initrd 中，您就可以将它们编译为模块。例如，发行版在安装时会在 initrd 中包含 / 文件系统、硬盘驱动器等。
答案2
据我所知，速度没有区别。
我认为您将获得几 kB 的内核内存，因为分配的粒度是一页，因此在典型的体系结构中，每个模块平均会浪费大约 2 kB（1/2 页）。即使在嵌入式系统上，这也没什么意义。您还可以获得一点磁盘空间，因为模块可以与内核在同一个 go 中进行压缩；这在存储空间很少的嵌入式系统中可能更相关。
如果您可以完全放弃模块，则可以节省一点内核内存（不需要模块加载器）、磁盘空间（不需要模块实用程序）和系统复杂性（不需要将模块加载作为发行版中的功能） ）。这些点在一些硬件不可扩展的嵌入式设计中相当有吸引力。
答案3
有几个潜在的好处。性能是一个值得商榷的问题。您可以避免与动态加载程序相关的一些运行时开销，但我怀疑这没什么大不了的，除非您依赖实时调度程序。
如果您正在利用系统上的大页面，那么创建更大的静态内核映像可能意味着您可以更有效地使用页面描述符缓存。一些系统会将内核“关在笼子里”，以便它紧密地打包到一个内存位置，这可以减轻由于轻微甚至可能严重的页面错误而造成的一定程度的延迟。
从架构上来说，交付一个大图像可能适合您，认为更少的独立模块更容易维护，并且灵活性的损失并不重要。许多此类推理都涉及风格和实践问题。
答案4
我静态编译内核内内置硬件的每个驱动程序。例外情况是非永久性硬件（例如 USB 连接硬件）。
由于我的硬件配置不太可能很快改变，所以我不关心模块。