在内核内部编译内核模块的好处？

将内核模块（而不是可加载模块）编译到内核中有什么好处？

这取决于。如果您的内存量很少，则模块的使用可能会改善简历，因为它们不会每次都重新加载（我发现这对2 GiB的RAM很重要，而对传统硬盘驱动器的4 GiB却不重要）。当由于电池模块中的某些错误（无论是作为内置模块还是作为模块）而花费很长时间（几分钟）启动时，尤其如此。即使没有gentoo上的错误，我也systemd-analysis仅通过从静态编译的内核更改为模块就设法将时间（由报道）从33s 缩短到18s-“令人惊讶的是”内核的开始从9s更改为1.5s。

另外，当您不知道要使用什么硬件时，模块显然是有益的。

PS。您甚至可以将重要的驱动程序编译为模块，只要将它们包括在initrd中即可。例如，发行版将在安装时的initrd中包含/的文件系统，硬盘驱动器的驱动程序等。

据我所知，没有速度差异。

我认为，由于分配的粒度为一页，因此您将获得几kB的内核内存，因此在典型的体系结构上，每个模块平均浪费约2kB（1/2页）的内存。即使在嵌入式系统上，这也并不重要。您还可以获得一点磁盘空间，因为可以像内核一样压缩模块。在存储量很少的嵌入式系统中，这可能更为相关。

如果可以完全省去模块，那么可以节省一点内核内存（不需要模块加载器），磁盘空间（不需要模块实用程序）和系统复杂性（不需要在发行版中包含模块加载功能） ）。这些点在某些硬件无法扩展的嵌入式设计中非常有吸引力。

有几个潜在的好处。性能是有争议的。您可以避免与动态加载程序相关的一些运行时开销，但是除非您依赖实时调度程序，否则我怀疑这是一个大问题。

如果您要利用系统上的大页面，则可能创建更大的静态内核映像意味着您可以更有效地利用页面描述符缓存。某些系统会“限制”内核，以便将内核紧密封装在一个内存区域中，这可以减轻由于较小（甚至可能是较大的）页面错误而引起的某些延迟。

从体系结构上讲，它可能适合您提供一个大形象，认为较少的独立模块更易于维护，而灵活性的丧失并不重要。许多这种推理都涉及样式和实践问题。

有时这是必要的。如果将一些重要的驱动程序（例如SCSI驱动程序）编译为模块，则系统将无法启动。

不作为模块编译的另一个不错的选择是根分区的文件系统类型。如果内核不懂ext3阅读/lib/modules/，它将如何从中加载模块？

可以这样考虑：使用内核模块需要对系统有足够的了解才能读取和加载内核模块。用那个和试错:-)

我为内核中的内置硬件静态编译了每个驱动程序。异常的硬件不是永久性的（例如，usb连接的硬件）。

由于我的硬件配置不太可能很快改变，因此我不必理会模块。