소스 코드에 Linux 커널 드라이버(커널 개체 KO)를 제공하고 이를 대상 컴퓨터에 빌드 및 설치하는 것이 일반적인 관행입니다. 예를 들어 NVIDIA 디스플레이 드라이버와 Oracle VirtualBox 게스트 추가 기능 드라이버는 이 방식으로 설치됩니다. 시스템 업데이트를 통해 (적절한 헤더가 포함된) 커널의 새 버전을 받는 것도 일반적입니다. 이를 위해서는 KO를 재구축하고 재설치해야 합니다. 그렇지 않으면 업데이트 후 장치 작동이 중지됩니다.
제품 설치 시작 스크립트에서 부팅할 때마다 KO를 만들고 설치하는 단계를 추가하려고 합니다. 사용자는 옵트아웃을 선택할 수 있으며 KO를 수동으로 구축하고 설치해야 합니다. 장치 드라이버는 USB 장치와 통신합니다.
관련 세부정보:
실제 재빌드는 새 커널이 설치될 때 한 번만 발생합니다. 왜냐하면 make는 이미 존재하고 최신 파일을 재빌드하려고 시도하지 않기 때문입니다.
드라이버를 다시 빌드하는 데 약 2초가 걸리고 일반 부팅 중(커널 업데이트 이후가 아님) 빌드를 건너뛰는 데 밀리초 정도 걸립니다.
드물지만 빌드가 실패하는 경우 시스템이 충돌하거나 불안정해져서는 안 됩니다. 그러나 우리의 하드웨어 장치는 작동하지 않습니다.
일부 배포판에서는 커널 업데이트와 같은 특정 이벤트에 대한 작업을 수행하기 위해 후크를 등록할 수 있습니다. 그러나 우리는 대부분의 배포판에서 균일한 방식으로 작동하는 것을 구현하려고 노력하고 있습니다. 설치 프로그램은 script+tar 또는 script+rpm입니다. 불행하게도 이번 릴리스에서는 모든 배포판(예: Debian 스타일)에 대한 기본 패키지를 준비할 수 있는 대역폭이 없습니다.
질문:
이것이 허용 가능한 솔루션입니까? 그렇지 않다면 왜 그렇습니까?
이 접근 방식과 관련된 잠재적 위험은 무엇입니까?
시작하는 동안 실행하기에 올바른/선호되는 장소는 무엇입니까? rc.local 또는 init.d 또는 기타 아래의 스크립트? 목표는 동일한 방법을 사용하여 대부분의 배포판에서 작동하도록 하는 것입니다(가능한 경우).
답변1
이 정답은 어제 ServerFault의 Rosco가 제공했습니다.
예, 하지만 스크립트가 정상적으로 반환되는지 확인할 수 있도록 스크립트를 수동으로 실행할 수 있는 방법을 설명하는 명확한 방법을 추가해야 합니다. 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는 데몬에 대한 추가 정보를 원할 때 가장 먼저 확인하는 곳입니다. 나는 괜찮아요.