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