Wann sollte ich ein Linux-Kernel-Modul schreiben?

Question

Einige Leute möchten aus irgendeinem Grund Code aus dem User-Space in den Kernel-Space in Linux verschieben. Oft scheint der Grund dafür zu sein, dass der Code eine besonders hohe Priorität haben sollte oder einfach "Kernel Space ist schneller".

Das scheint mir seltsam. Wann sollte ich ein Kernel-Modul schreiben? Gibt es eine Reihe von Kriterien?

Wie kann ich motivieren, Code im Benutzerbereich zu behalten, der (glaube ich) dort hingehört?

Answer 1

Ich bin mir nicht sicher, ob die Frage richtig ist. Es sollte einen guten Grund geben, Dinge in den Kernel-Bereich zu verschieben. Wenn es keine Gründe gibt, tu es nicht.

Zum einen wird das Debuggen erschwert, und die Auswirkungen von Fehlern sind viel schlimmer (Absturz/Panik anstelle von einfachem Arbeitsspeicher).

Answer 2

Code, der im Kernel läuft, greift auf Speicher, Peripheriegeräte, Systemfunktionen in einer Weise zu, die sich vom Userspace-Code unterscheidet und somit effizienter sein kann. Ganz zu schweigen von den reduzierten Sicherheitsbeschränkungen für Kernel-Code. Dies alles hat jedoch normalerweise seinen Preis, beispielsweise die Möglichkeit, den Kernel gegen Sicherheitsbedrohungen zu öffnen, das Betriebssystem zu sperren, das Debuggen zu erschweren und so weiter.

Answer 3

Es gibt sehr begrenzte Gründe, Sachen in den Kernel zu legen. Wenn Sie Gerätetreiber schreiben, ist es in Ordnung. Jede Standardanwendung: niemals.

Die Nachteile sind riesig. Das Debuggen wird schwieriger, Fehler werden häufiger und sind schwer zu finden. Sie könnten Sicherheit und Stabilität gefährden. Sie müssen sich möglicherweise häufiger an Änderungen des Kernels anpassen. Es wird unmöglich, auf andere UNIX-Betriebssysteme zu portieren.

Der nächste, den ich jemals zum Kernel kam, war ein benutzerdefiniertes Dateisystem (mit mysql im Hintergrund) und sogar dafür verwendeten wir FUSE (wo das U für Userspace steht).

Answer 4

Als allgemeine Regel. Denken Sie darüber nach, was Sie wissen möchten, und wenn das etwas ist, das Sie in einem Betriebssystementwicklungsbuch oder einer Klasse sehen würden, dann hat es eine gute Chance, in den Kernel zu gehören. Wenn nicht, lass es aus dem Kernel. Wenn Sie einen sehr guten Grund haben, diese Regel zu brechen, seien Sie sicher, Sie werden genug Wissen haben, um es selbst zu kennen, oder Sie werden mit jemandem arbeiten, der dieses Wissen besitzt.

Ja, könnte hart klingen, aber das genau, was ich meinte, wenn Sie nicht wissen, dann bin fast sicher, die Antwort ist nein, tun Sie es nicht im Kernel. Wenn Sie Ihre Entwicklung in den Kernel-Bereich verschieben, öffnet sich eine riesige Anzahl von Würmern, mit denen Sie sicher umgehen können.

Answer 5

Faustregel: versuchen Sie Ihren absoluten besten, um Ihren Code in User-Space zu halten. Wenn Sie nicht denken, dass Sie können, verbringen Sie so viel Zeit, Alternativen zum Kernel-Code zu erforschen, wie Sie den Code schreiben würden (zB: eine lange Zeit), und versuchen Sie es erneut , um es in User-Space zu implementieren. Wenn Sie immer noch können nicht, Forschung mehr, um sicherzustellen, dass Sie die richtige Wahl treffen, dann sehr vorsichtig in den Kernel bewegen. Wie andere gesagt haben, gibt es sehr wenige Umstände, die das Schreiben von Kernel-Modulen und Debugging-Kernel-Code diktieren, kann ziemlich höllisch sein, so um jeden Preis zu steuern.

Soweit konkrete Bedingungen, die Sie beim Schreiben von Kernel-Modus-Code überprüfen sollten, sind hier ein paar: Benötigt es Zugriff auf extrem Low-Level-Ressourcen, wie Interrupts?Definiert Ihr Code eine neue Schnittstelle/einen neuen Treiber für Hardware, die nicht auf der aktuell exportierten Funktionalität aufbauen kann? Benötigt Ihr Code Zugriff auf Datenstrukturen oder Primitive, die nicht aus dem Kernelraum exportiert werden? Schreiben Sie etwas, das in erster Linie von Kernel-Subsystemen wie einem Scheduler oder VM-System verwendet wird (auch hier ist es nicht unbedingt notwendig, dass das Subsystem Kernel-Modus ist: Mach User-ModusBenutzermodus wird andere virtuelle Speicher Pager, so kann es definitiv getan werden)?

Answer 6

Wenn Ihre Leute wirklich hohe Priorität, Determinismus, niedrige Latenz usw. wollen, ist der richtige Weg, eine Echtzeitversion von Linux (oder einem anderen Betriebssystem) zu verwenden.

Schauen Sie sich auch die präemptiven Kernel-Optionen usw. an. Was Sie tun sollten, hängt von den Anforderungen ab, aber den Code in Kernel-Module zu stecken ist wahrscheinlich nicht die richtige Lösung, es sei denn, Sie schließen Hardware direkt an.

Answer 7

Wenn Sie nur niedrigere Latenz, höheren Durchsatz, etc. benötigen, ist es wahrscheinlich billiger, einen schnelleren Computer als Kernel-Code zu kaufen.

Kernel Module kann schneller (durch weniger Kontextwechsel, weniger Systemaufruf Aufwand und weniger Unterbrechungen) und sicherlich bei sehr hohen Priorität Lauf tun. Wenn Sie eine kleine Menge ziemlich einfachen Codes in den Kernelbereich exportieren möchten, ist dies möglicherweise in Ordnung. Das heißt, wenn ein kleines Stück Code für die Leistung entscheidend ist, und ist die Art von Code, der davon profitieren würde, in den Kernel-Modus versetzt zu werden, dann kann es gerechtfertigt sein, ihn dort zu platzieren.

Das Verschieben großer Teile Ihres Programms in den Kernel-Bereich sollte jedoch vermieden werden, sofern nicht alle anderen Optionen vollständig ausgeschöpft sind. Abgesehen von der Schwierigkeit, dies zu tun, wird der Leistungsvorteil wahrscheinlich nicht sehr groß sein.

Answer 8

Grundsätzlich stimme ich mit rpj. Code muss im User-Space sein, es sei denn, es ist WIRKLICH notwendig.

Aber, um Ihre Frage zu betonen, welche Bedingung?

Einige Leute behaupten, dass der Treiber im Kernel sein muss, was nicht wahr ist. Einige Treiber sind nicht Timing-empfindlich, in der Tat sind viele Treiber so.

Zum Beispiel der Framer, RTC-Timer, i2c-Geräte, etc. Diese Treiber können leicht in den Benutzerbereich verschoben werden. Es gibt sogar einige Dateisysteme, die im User-Space geschrieben sind.

Sie sollten zum Kernel-Space, wo der Overhead, z. Benutzer-Kernel-Swap, wird inakzeptabel für Ihren Code ordnungsgemäß funktionieren.

Aber es gibt viele Möglichkeiten, damit umzugehen. Zum Beispiel bietet das/dev/mem eine gute Möglichkeit, auf Ihren physischen Speicher zuzugreifen, genau wie Sie es aus dem Kernel-Bereich tun.

Wenn Leute über RTOS sprechen, bin ich normalerweise skeptisch. Heutzutage ist der Prozessor so leistungsfähig, dass der Echtzeitaspekt in den meisten Fällen vernachlässigbar wird.

Aber sogar, sagen wir, Sie haben mit SONET zu tun, und Sie müssen einen Schutz innerhalb von 50ms (tatsächlich noch weniger, da die 50ms Einschränkungen für den gesamten Ring gilt) tun, können Sie immer noch die Umschaltung sehr tun schnell, wenn Ihre Hardware dies unterstützt.

Viele Framer in diesen Tagen können Ihnen eine Hardware-Unterstützung geben, die die Menge der Schreibvorgänge reduziert, die Sie tun müssen. Ihr Job reagiert im Grunde so schnell wie möglich auf den Interrupt. Und Linux ist überhaupt nicht schlecht. Die Interrupt-Latenz, die ich bekam, war weniger als 1 ms, selbst wenn ich viele andere Interrupts laufen habe (zB IDE, Ethernet, etc.).

Und wenn das immer noch nicht genug ist, dann ist vielleicht Ihr Hardware-Design falsch. Einige Dinge sind besser auf der Hardware. Und wenn ich Hardware sagte, meine ich ASIC, FPGA, Netzwerkprozessor oder andere fortgeschrittene Logik.

Answer 9

Wenn Sie eine solche Frage stellen, sollten Sie nicht zur Kernel-Ebene gehen. Im Grunde nur wundern bedeutet, dass Sie nicht müssen. Die Zeit des Kontextwechsels ist so vernachlässigbar, dass es heutzutage ohnehin keine Rolle spielt.

Answer 10

Ein weiterer Grund, Code nicht in den Kernel-Space zu verschieben, ist, dass Sie diesen Code aufgrund der GPL-Vereinbarung veröffentlichen müssen, wenn Sie ihn in Produktions- oder kommerziellen Situationen verwenden. Eine Situation, in die viele Softwarefirmen nicht kommen wollen. :)