常见的做法是在源代码中提供 Linux 内核驱动程序（内核对象 KO），然后在目标计算机上构建和安装它们。例如，Nvidia 显示驱动程序、Oracle VirtualBox 客户机附加驱动程序就是以这种方式安装的。通过系统更新接收新版本的内核（带有适当的标头）也很常见。这需要重新构建和重新安装 KO，否则设备将在更新后停止工作。
在我们的产品安装启动脚本中，我们希望添加在每次启动时制作和安装 KO 的步骤。用户可以选择退出，并且必须手动构建和安装 KO。设备驱动程序与 USB 设备通信。相关详细信息：1. 实际重建只会在安装新内核时发生一次，因为 make 不会尝试重建已经存在且最新的文件。2. 重建驱动程序大约需要 2 秒，在正常启动期间（不是在内核更新后）跳过构建需要几毫秒3. 万一构建失败，它不应该导致系统崩溃或不稳定，但是我们的硬件设备将无法工作。4. 某些发行版可能允许注册钩子，以对某些事件（如内核更新）执行操作。但是，我们正在尝试以统一的方式实现在大多数发行版上都能正常工作的东西。我们的安装程序是脚本 + tar 或脚本 + rpm。不幸的是，对于此版本，我们没有足够的带宽来为所有发行版准备本机包（例如 debian 风格）。
问题：1. 这是一个可以接受的解决方案吗？如果不是，为什么？2. 这种方法有哪些潜在风险？3. 启动时运行 make 的正确/首选位置是哪里？rc.local 还是 init.d 下的脚本，还是其他？目标是使用相同的方法使其在大多数发行版上工作（如果可能的话）。
答案1
1) 是的，但你应该添加一个清晰的操作说明，描述我们可以手动运行脚本的方式，这样我们就可以确保脚本正常返回。在 centos 中的 virtualbox 中，他们在 /etc/init.d 中添加了一个名为 vboxdrv 的脚本
用法：/etc/init.d/vboxdrv {start|stop|stop_vms|restart|force-reload|status|setup}
这很清楚，我们可以启动/停止脚本并获取其状态，因此只要我们可以在部署新内核之前检查脚本，重启时出现问题的风险就很小。没有比这更标准的了，对我来说这是完美的。
2) 编译过程系统性失败，没有可用的模块。有这么悲惨吗？我不这么认为。只要您的脚本不会挂起机器，并且您在 /var/log/mymodule 中提供编译失败的完整日志，您就无法做得更好了。
3) 参见 1) 在 centos/RHEL/fedora 上，vboxdrv 从 /etc/init.d/vboxdrv 运行并检查发行版名称，然后相应地获取一些脚本。当我想了解有关守护进程的更多信息时，/etc/init.d 是我首先检查的地方。我对此很满意。
答案2
这取决于您的硬件。
如果您这样做，请确保您的脚本在几秒钟内超时，否则您可能会有很多管理员想知道为什么在国家另一端的主机托管设施中的某些机器在内核升级后没有重新启动。
如果你的硬件对于启动过程至关重要（可能是网络适配器或 USB 驱动器），那么需要更早完成（可能前新内核启动后才会启动）。否则，您需要尽可能晚地完成此操作，以确保编译器可能需要的任何网络挂载文件系统都已到位。这还有助于确保 MTA 正在运行，这样如果由于某种原因无法构建模块，您的构建过程就可以向 root 发送电子邮件。