Es ist üblich, Linux-Kerneltreiber (Kernelobjekte, KOs) im Quellcode bereitzustellen und sie auf dem Zielcomputer zu erstellen und zu installieren. Beispielsweise werden NVIDIA-Grafiktreiber und Oracle VirtualBox-Gast-Add-On-Treiber auf diese Weise installiert. Es ist auch üblich, neue Versionen des Kernels (mit entsprechenden Headern) über ein Systemupdate zu erhalten. Dazu muss das KO neu erstellt und neu installiert werden, da das Gerät sonst nach dem Update nicht mehr funktioniert.
In unserem Startskript für die Produktinstallation möchten wir den Schritt hinzufügen, bei jedem Start das KO zu erstellen und zu installieren. Der Benutzer kann sich dagegen entscheiden und müsste das KO manuell erstellen und installieren. Der Gerätetreiber kommuniziert mit einem USB-Gerät.
Angaben zur Sache:
Der eigentliche Neuaufbau erfolgt nur einmal, wenn der neue Kernel installiert wird, da make nicht versucht, die bereits vorhandene und aktuelle Datei neu aufzubauen.
Es dauert etwa zwei Sekunden, den Treiber neu zu erstellen, und Millisekunden, um den Build während des normalen Bootvorgangs zu überspringen (nicht nach einem Kernel-Update).
Im unwahrscheinlichen Fall, dass der Build fehlschlägt, sollte das System dadurch nicht abstürzen oder instabil werden. Unser Hardwaregerät wird jedoch nicht funktionieren.
Einige Distributionen erlauben möglicherweise die Registrierung von Hooks, um bei bestimmten Ereignissen Aktionen auszuführen, wie z. B. Kernel-Updates. Wir versuchen jedoch, etwas zu implementieren, das auf den meisten Distributionen einheitlich funktioniert. Unser Installationsprogramm ist script+tar oder script+rpm. Leider haben wir für diese Version nicht die Bandbreite, um native Pakete für alle Distributionen vorzubereiten (z. B. im Debian-Stil).
Fragen:
Ist das eine akzeptable Lösung? Wenn nicht, warum?
Welche potenziellen Risiken sind mit diesem Ansatz verbunden?
Was ist der richtige/bevorzugte Ort, um make während des Starts auszuführen? rc.local oder ein Skript unter init.d oder etwas anderes? Das Ziel ist, es auf den meisten Distributionen mit derselben Methode zum Laufen zu bringen (falls das überhaupt möglich ist).
Antwort1
Diese richtige Antwort wurde gestern von Rosco auf ServerFault bereitgestellt.
Ja, aber Sie sollten eine klare Anleitung hinzufügen, die beschreibt, wie wir Ihr Skript manuell ausführen können, damit wir sicherstellen können, dass das Skript normal zurückkehrt. Im Fall von VirtualBox in CentOS fügen sie in /etc/init.d ein Skript namens vboxdrv hinzu:
/etc/init.d/vboxdrv {start|stop|stop_vms|restart|force-reload|status|setup}Das ist klar; wir können das Skript starten/stoppen und seinen Status abrufen, sodass das Risiko von Problemen beim Neustart minimal ist, solange wir das Skript vor der Bereitstellung auf einem neuen Kernel überprüfen können. Mehr Standard geht nicht, für mich ist das perfekt.
Systematischer Fehler beim Kompilieren und kein Modul verfügbar. Ist das so tragisch? Ich glaube nicht. Solange Ihr Skript die Maschine nicht hängen lässt und Sie ein vollständiges Protokoll des Kompilierungsfehlers in /var/log/mymodule angeben, können Sie es nicht besser machen.
Siehe 1. – unter CentOS/RHEL/Fedora) läuft vboxdrv von /etc/init.d/vboxdrv und prüft den Distributionsnamen, dann werden einige Skripte entsprechend als Quelle verwendet. /etc/init.d ist der erste Ort, den ich überprüfe, wenn ich weitere Informationen zu einem Daemon haben möchte. Für mich ist das in Ordnung.