Czy ryzykowne jest udostępnienie opcji tworzenia i instalowania nowego jądra systemu Linux i sterownika podczas ponownego uruchamiania?

Powszechną praktyką jest dostarczanie sterowników jądra systemu Linux (obiektów jądra KO) do kodu źródłowego i budowanie i instalowanie ich na komputerze docelowym. Na przykład sterowniki wyświetlania NVIDIA i dodatkowe sterowniki Oracle VirtualBox są instalowane w ten sposób. Powszechne jest również otrzymywanie nowych wersji jądra (z odpowiednimi nagłówkami) poprzez aktualizację systemu. Wymaga to ponownego zbudowania i ponownego zainstalowania KO, w przeciwnym razie urządzenie przestanie działać po aktualizacji.

W naszym skrypcie startowym instalacji produktu chcemy dodać krok do wykonania i instalacji KO przy każdym starcie. Użytkownik może zrezygnować i musiałby ręcznie zbudować i zainstalować KO. Sterownik urządzenia komunikuje się z urządzeniem USB.

Szczegółowe informacje:

1. Rzeczywista ponowna kompilacja będzie miała miejsce tylko raz po zainstalowaniu nowego jądra, ponieważ make nie będzie próbował ponownie skompilować pliku, który już istnieje i jest aktualny.

2. Przebudowanie sterownika zajmuje około dwóch sekund, a milisekundy pominięcie kompilacji podczas normalnego rozruchu (nie po aktualizacji jądra)

3. W mało prawdopodobnym przypadku, gdy kompilacja się nie powiedzie, nie powinna zawieść systemu lub spowodować jego niestabilności. Jednak nasze urządzenie nie będzie działać.

4. Niektóre dystrybucje mogą zezwalać na rejestrowanie haków, wykonywanie działań na określonych zdarzeniach, takich jak aktualizacja jądra. Próbujemy jednak zaimplementować coś, co będzie działać na większości dystrybucji w jednolity sposób. Nasz instalator to skrypt + tar lub skrypt + rpm. Niestety dla tego wydania nie mamy przepustowości, aby przygotować pakiety natywne dla wszystkich dystrybucji (na przykład w stylu Debiana).

Pytania:

1. Czy to akceptowalne rozwiązanie? Jeśli nie, dlaczego?

2. Jakie są potencjalne zagrożenia związane z tym podejściem?

3. Jakie jest właściwe / preferowane miejsce do uruchomienia podczas uruchamiania? rc.local lub skrypt w init.d lub innym? Celem jest sprawienie, aby działał w większości dystrybucji przy użyciu tej samej metody (jeśli w ogóle jest to możliwe).

Ta poprawna odpowiedź została wczoraj dostarczona przez Rosco na ServerFault.

1. Tak, ale powinieneś dodać jasne instrukcje opisujące sposób ręcznego uruchomienia skryptu, abyśmy mogli upewnić się, że skrypt powróci normalnie. W przypadku VirtualBox w CentOS dodają skrypt w /etc/init.d o nazwie vboxdrv:

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

   To jest jasne; możemy uruchomić / zatrzymać skrypt i uzyskać jego status, więc ryzyko wystąpienia problemów przy ponownym uruchomieniu jest minimalne, o ile możemy sprawdzić skrypt na nowym jądrze przed jego wdrożeniem. Nie możesz mieć więcej niż to, dla mnie to jest idealne.

2. Systematyczne niepowodzenie procesu kompilacji i brak dostępnego modułu. Czy to jest takie tragiczne? Nie sądzę. Dopóki skrypt nie zawiesza komputera i podajesz pełny dziennik awarii kompilacji w / var / log / mymodule, nie możesz zrobić tego lepiej.

3. Zobacz 1. - w CentOS / RHEL / Fedora) vboxdrv działa z /etc/init.d/vboxdrv i sprawdza nazwę dystrybucji, a następnie odpowiednio źródła niektórych skryptów. /etc/init.d to pierwsze miejsce, które sprawdzam, gdy chcę uzyskać więcej informacji o demonie. Dla mnie jest w porządku.