É arriscado dar a opção de fazer e instalar um novo kernel Linux e driver na reinicialização?

Question

É uma prática comum fornecer drivers de kernel do Linux (KOs de objetos do kernel) no código-fonte e compilá-los e instalá-los no computador de destino. Por exemplo, os drivers de vídeo NVIDIA e os complementos de convidados do Oracle VirtualBox são instalados dessa forma. Também é comum receber novas versões do kernel (com cabeçalhos apropriados) por meio da atualização do sistema. Isso requer que o KO seja reconstruído e reinstalado, caso contrário, o dispositivo deixará de funcionar após a atualização.

Em nosso script de inicialização da instalação do produto, queremos adicionar a etapa para criar e instalar o KO em cada inicialização. O usuário pode optar por desativar e teria que criar e instalar o KO manualmente. O driver de dispositivo se comunica com um dispositivo USB.

Detalhes pertinentes:

1. A real reconstrução só acontecerá uma vez quando o novo kernel estiver instalado, porque o make não tentará reconstruir o arquivo que já está lá e está atualizado.

2. Demora cerca de dois segundos para reconstruir o driver, e milissegundos para pular a compilação durante a inicialização normal (não após a atualização do kernel)

3. No caso improvável de a compilação falhar, ela não deve travar o sistema nem torná-lo instável. No entanto, nosso dispositivo de hardware não funcionará.

4. Algumas distribuições podem permitir o registro de ganchos, para fazer ações em certos eventos, como a atualização do kernel. No entanto, estamos tentando implementar algo que funcione na maioria das distribuições de maneira uniforme. Nosso instalador é script + tar ou script + rpm. Infelizmente para esta versão, não temos largura de banda para preparar pacotes nativos para todas as distribuições (por exemplo, estilo Debian).

Perguntas:

1. Esta é uma solução aceitável? Se não, por quê?

2. Quais são os riscos potenciais associados a essa abordagem?

3. Qual é o local correto / preferido para executar durante a inicialização? rc.local ou script sob init.d ou outro? O objetivo é fazê-lo funcionar na maioria das distribuições usando o mesmo método (se possível).

Answer 1

Esta resposta correta foi fornecida pela Rosco no ServerFault ontem.

1. Sim, mas você deve adicionar um tutorial claro descrevendo a maneira como podemos executar seu script manualmente para que possamos ter certeza de que o script retornará normalmente. No caso do VirtualBox no CentOS, eles adicionam um script em /etc/init.d chamado vboxdrv:

   /etc/init.d/vboxdrv {start|stop|stop_vms|restart|force-reload|status|setup}
   

   Isso está claro; Podemos iniciar / parar o script e obter seu status, portanto, o risco de obter problemas no momento da reinicialização é mínimo, desde que possamos verificar o script em um novo kernel antes de implantá-lo. Você não pode ter mais padrão do que isso, para mim é perfeito.

2. Falha sistemática do processo de compilação e nenhum módulo disponível. Isso é trágico? Acho que não. Enquanto o seu script não travar a máquina e você fornecer um registro completo da falha de compilação em / var / log / mymodule, não será possível fazer melhor do que isso.

3. Veja 1. - no CentOS / RHEL / Fedora) o vboxdrv é executado a partir do /etc/init.d/vboxdrv, verifica o nome da distribuição e, em seguida, fornece alguns scripts de acordo. /etc/init.d é o primeiro lugar que eu verifico quando quero mais informações sobre um daemon. Está tudo bem comigo.