Es una práctica común entregar controladores del kernel de Linux (objetos del kernel KO) en el código fuente y compilarlos e instalarlos en la computadora de destino. Por ejemplo, los controladores de pantalla NVIDIA y los controladores complementarios para invitados de Oracle VirtualBox se instalan de esta manera. También es común recibir nuevas versiones del kernel (con los encabezados apropiados) mediante la actualización del sistema. Esto requiere que el KO se reconstruya y se reinstale; de lo contrario, el dispositivo dejará de funcionar después de la actualización.
En nuestro script de inicio de instalación del producto queremos agregar el paso para crear e instalar el KO en cada arranque. El usuario puede optar por no participar y tendrá que crear e instalar el KO manualmente. El controlador del dispositivo se comunica con un dispositivo USB.
Detalles pertinentes:
La reconstrucción real ocurrirá sólo una vez cuando se instale el nuevo kernel, porque make no intentará reconstruir el archivo que ya está ahí y actualizado.
Se necesitan aproximadamente dos segundos para reconstruir el controlador y milisegundos para omitir la compilación durante el arranque normal (no después de la actualización del kernel).
En el improbable caso de que la compilación falle, no debería bloquear el sistema ni volverlo inestable. Sin embargo, nuestro dispositivo de hardware no funcionará.
Algunas distribuciones pueden permitir registrar enlaces para realizar acciones en ciertos eventos, como la actualización del kernel. Sin embargo, estamos intentando implementar algo que funcione en la mayoría de las distribuciones de forma uniforme. Nuestro instalador es script+tar o script+rpm. Desafortunadamente para esta versión no tenemos ancho de banda para preparar paquetes nativos para todas las distribuciones (por ejemplo, estilo Debian).
Preguntas:
¿Es esta una solución aceptable? Si no, ¿por qué?
¿Cuáles son los riesgos potenciales asociados con este enfoque?
¿Cuál es el lugar correcto/preferido para ejecutar durante el inicio? ¿rc.local o script en init.d u otro? El objetivo es hacer que funcione en la mayoría de las distribuciones utilizando el mismo método (si es posible).
Respuesta1
Esta respuesta correcta fue proporcionada ayer por Rosco en ServerFault.
Sí, pero debe agregar un procedimiento claro que describa la forma en que podemos ejecutar su secuencia de comandos manualmente para que podamos asegurarnos de que la secuencia de comandos regrese normalmente. En el caso de VirtualBox en CentOS agregan un script en /etc/init.d llamado vboxdrv:
/etc/init.d/vboxdrv {start|stop|stop_vms|restart|force-reload|status|setup}Esto está claro; Podemos iniciar/detener el script y obtener su estado, por lo que el riesgo de tener problemas al reiniciar es mínimo siempre que podamos verificar el script en un nuevo kernel antes de implementarlo. No puedes tener más estándar que este, para mí es perfecto.
Fallo sistemático del proceso de compilación y ningún módulo disponible. ¿Es así de trágico? No me parece. Mientras su script no cuelgue la máquina y proporcione un registro completo del error de compilación en /var/log/mymodule, no podrá hacerlo mejor que eso.
Consulte 1. - en CentOS/RHEL/Fedora), vboxdrv se ejecuta desde /etc/init.d/vboxdrv y verifica el nombre de la distribución, luego obtiene algunos scripts en consecuencia. /etc/init.d es el primer lugar que reviso cuando quiero más información sobre un demonio. Está bien conmigo.