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

Question

É uma prática comum fornecer drivers de kernel Linux (KOs de objetos de 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 drivers complementares convidados do Oracle VirtualBox são instalados dessa maneira. Também é comum receber novas versões do kernel (com cabeçalhos apropriados) através de atualização do sistema. Isso requer que o KO seja reconstruído e reinstalado, caso contrário o dispositivo irá parar de funcionar após a atualização.

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

Detalhes pertinentes:

1. A reconstrução real acontecerá apenas uma vez quando o novo kernel for instalado, porque o make não tentará reconstruir o arquivo que já está lá e 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 ou torná-lo instável. No entanto, nosso dispositivo de hardware não funcionará.

4. Algumas distribuições podem permitir registrar ganchos, para realizar ações em determinados eventos, como atualização do kernel. Porém, 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).

Questões:

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

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

3. Qual é o local correto/preferido para execução durante a inicialização? rc.local ou script em 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 por 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}
   

   Isto é claro; podemos iniciar/parar o script e obter seu status, portanto o risco de 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 que isso, para mim é perfeito.

2. Falha sistemática do processo de compilação e nenhum módulo disponível. É tão trágico? Eu não acho. Contanto que seu script não trave a máquina e você forneça um log completo da falha de compilação em/var/log/mymodule, você não pode fazer melhor do que isso.

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