Was sind gute und schlechte Dinge im Design des Linux-Kernels?

Question

Ich bin kein Meister des Kernel-Codes, habe aber eine Grundidee seiner Code-Struktur. In diesem Post können wir diskutieren, was das Gute und das Schlechte im Design des Kernels ist.

Update: Nein, das ist nicht für Hausaufgaben. Ich hätte das erwähnt, wenn das der Fall wäre.

sehen: https://stackoverflow.com/questions/1548442/i-know-how-to-program-now-how-do-i-learn-to-design

Jeder das Design des Linux-Kernels lobt. Lassen Sie uns eine Liste der guten und schlechten Design-Entscheidungen, die im Design des Kernels getroffen wurden.

Answer 1

gibt es einen Artikel namens "Linux Kernel Design Patterns". Sie finden verschiedene Muster für Design-Kernel für Linux. Ein Artikel, der kontinuierlich ist "Linux Kernel Design Patterns - Part 1", starten Sie von diesem und googeln für zusätzlichen Artikel für Kernel Design Pattern.

Answer 2

Ich denke, diese http://linuxhelp.blogspot.com/2006/05/monolithic-kernel-vs-microkernel-which.html sollte etwas Licht auf Ihre Frage leuchten.

Answer 3

Schlimmste:

Das Build-System, (ja, ich weiß, es ist nichts mit dem Design des Kernels selbst zu tun).
Es ist ein absoluter Alptraum, nichts wie irgendein anderes in der Existenz, und wenn aus irgendeinem Grund (Hinzufügen einer neuen Architektur, vielleicht) Sie es ändern müssen, müssen Sie eine ganz neue Sprache dazu lernen.

Beste Sache:

Fast alles ist konfigurierbar. Es ist erstaunlich, dass im Grunde der gleiche Kernel in winzigen eingebetteten Geräten ohne MMU und in Supercomputern mit riesigen Speichern und Tausenden von Prozessoren verwendet wird.

Answer 4

Nicht direkt über Linux-Design, aber ich glaube, der Entwicklungsprozess dahinter ist der bemerkenswerteste. Der Kernel selbst entwickelt sich ständig weiter und das mit unglaublicher Geschwindigkeit. Dies ist nur durch die dezentrale Versionskontrolle (git) möglich, die es einer sehr großen Anzahl von Entwicklern ermöglicht, gleichzeitig zu arbeiten.

Auch mit git bisect haben sie etwas bemerkenswertes erreicht; Es ist nun möglich, dass Nicht-Entwickler Fehler aufspüren. Hier ist ein Zitat von David Miller:

Was Menschen nicht bekommen, ist, dass dies eine Situation, in der „Endknoten Prinzip“ gilt. Wenn Sie begrenzte Ressourcen haben (hier: Entwickler) schieben Sie nicht den Großteil der Belastung auf sie. Stattdessen schieben Sie Dinge auf die Ressource, die Sie haben viele, die Endknoten (hier: Benutzer), so dass die Situation tatsächlich skaliert.

Menschen einen Fehler haben Zugriff auf die Umwelt berichten, wo der Fehler passiert, und „git bisect“ automatisch relevante Informationen aus dieser Umgebung extrahieren. Dies ist auch eine gute Möglichkeit, neue Mitwirkende zu bekommen.

Wenn Entwickler Code beisteuern möchten, müssen sie ihren Code unbedingt in kleine, separat anwendbare Patches unterteilen, damit jede Änderung leicht überprüft werden kann. Auf diese Weise kann ein großer Teil ihres Codes von vielen Menschen verstanden werden.

Die Linux Management Style ist eine interessante Lektüre. Linus versucht, eine Atmosphäre zu leben, in der man sich nicht hinter Höflichkeit versteckt, sondern klar angibt, was man denkt. Das mag manchmal etwas unhöflich sein, aber ich bin mir sicher, dass es die Codequalität auf hohem Niveau hält.

Answer 5

schlechte Dinge:

1. neue Funktion ist hoch und Bug-Fix-Zyklus für diese Funktion wenig.
2. Config-System muss intelligent sein. und kategorisiert für einige allgemeine Bedürfnisse. wenn es Assistenten wie Config-System und mehr Interaktionen und Infos bei der Konfiguration hat.
3. große Kernel-Sperre und andere Sperren überall ohne guten Prüfmechanismus.

gute Dinge:

1. Benutzermodus-Treiber: Benutzermodus-Dateisystem, Benutzermodus Blocktreiber, Benutzermodus Blocktreiber, roh versteckt, ...
2. guter Fahrer Inklusion. In diesen Tagen haben viele Geräte im Linux Kernel Unterstützung.
3. leichte Virtualisierung im Kernel.
4. gute Kommunikationsmechanismen zwischen Benutzerraum und Kernelraum (dev, proc, sys, debugfs, ...)
5. sehr gute Verwendung von C-Sprache mit Funktionszeigern an Strukturen, um einige objektorientierte Merkmale zu simulieren.
6. Benutzermodus Linux zum Debuggen.
7. gute Unterstützung von Embedded-Systemen
8. sehr gute Sicherheitsmechanismen: SELinux, AppArmor, Integritätsprüfung, ...

Answer 6

denke ich Kernel-Entwicklung, sondern als ein Design-Problem mit philosophischen Hintergründen und Debatten zu sein (wie als Mikrokern vs. monolithischen Kernel), ist ein Problem von praktischem Code, der zuverlässig funktioniert. Die Vielzahl von Peripherien und Protokollen, die ein Kernel zusätzlich zu der Vielzahl von Hardwareversionen und -herstellern unterstützen sollte, sowie komplexe Probleme, die bei der Entwicklung im Protected-Modus auftreten (im Gegensatz zur Benutzermodusentwicklung, die Anwendungen verwenden), rechtfertigen diese Aussage. Vergessen Sie auch nicht das Problem der Rückwärtskompatibilität, das für ein Betriebssystem in der Praxis wichtig ist, aber in der Designphilosophie hauptsächlich vernachlässigt wird. Der Linux-Kernel ist ein gutes Beispiel dafür: ein monolithischer Kernel (obwohl sehr modular) mit vielen pragmatischen Hacks, der viele gut durchdachte akademische oder kommerzielle Betriebssysteme hinsichtlich Popularität und Leistung sowohl im Server- als auch im eingebetteten Systembereich übertrifft.

Ein überragender Vorteil von Linux besteht darin, dass viele Aspekte seines Kernels entweder in das Kernel-Image (meist bzImage) eingebettet oder später als Kernel-Modul hinzugefügt werden können. Sie können es konfigurieren, bevor Sie das Kernel-Image mit dem Config-Tool erstellen, und dann kann jedes Kernel-Modul zur Laufzeit (natürlich durch root-Rechte) einfach entfernt oder hinzugefügt werden, ohne dass das Betriebssystem neu gestartet werden muss. Dies macht die Kernel-Entwicklung und Wartung wirklich einfacher.(Denken Sie nur an Windows-Betriebssystem, das für fast jedes Update einen Neustart benötigt, oft in nicht verwandten Programmen)