Was bringt es, einen eigenen Linux-Kernel zu kompilieren?

Welchen Nutzen könnte ich sehen, wenn ich selbst einen Linux-Kernel kompiliere? Gibt es eine Effizienz, die Sie durch Anpassen an Ihre Hardware erzielen können?

Meiner Meinung nach ist der einzige Vorteil, den Sie beim Kompilieren Ihres eigenen Linux-Kernels wirklich haben,:

Sie lernen, wie Sie Ihren eigenen Linux-Kernel kompilieren.

Es ist nichts, was Sie für mehr Geschwindigkeit / Speicher / xxx tun müssen . Es ist eine wertvolle Sache, wenn Sie sich in dieser Phase Ihrer Entwicklung befinden. Wenn Sie ein tieferes Verständnis dafür haben möchten, worum es bei dieser ganzen Open Source-Sache geht, wie und was die verschiedenen Teile des Kernels sind, sollten Sie es ausprobieren. Wenn Sie nur versuchen, die Startzeit um 3 Sekunden zu verkürzen, dann ... wozu ... kaufen Sie eine SSD. Wenn Sie neugierig sind, wenn Sie lernen möchten, dann ist das Kompilieren Ihres eigenen Kernels eine großartige Idee und Sie werden wahrscheinlich eine Menge davon haben.

Trotzdem gibt es einige spezifische Gründe, aus denen es angebracht wäre, Ihren eigenen Kernel zu kompilieren (wie mehrere Personen in den anderen Antworten ausgeführt haben). Im Allgemeinen ergeben sich diese aus einem bestimmten Bedarf, den Sie an einem bestimmten Ergebnis haben, zum Beispiel:

• Ich muss das System veranlassen, auf Hardware mit begrenzten Betriebsmitteln aufzuladen / zu laufen
• Ich muss einen Patch testen und den Entwicklern Feedback geben
• Ich muss etwas deaktivieren, das einen Konflikt verursacht
• Ich muss den Linux-Kernel entwickeln
• Ich muss die Unterstützung für meine nicht unterstützte Hardware aktivieren
• Ich muss die Leistung von x verbessern, weil ich die aktuellen Grenzen des Systems überschreite (und ich weiß, was ich tue)

Das Problem liegt in der Annahme, dass das Kompilieren Ihres eigenen Kernels einen wesentlichen Vorteil hat, wenn bereits alles so funktioniert, wie es sein sollte, und ich glaube nicht, dass dies der Fall ist. Obwohl Sie unzählige Stunden damit verbringen können, Dinge zu deaktivieren, die Sie nicht benötigen, und die Dinge zu optimieren, die optimiert werden können, ist der Linux-Kernel (von Ihrer Distribution) für die meisten Benutzersituationen bereits ziemlich gut optimiert .

Die meisten Benutzer müssen ihren eigenen Kernel nicht kompilieren, ihre Distribution hat diese Arbeit für sie erledigt. Normalerweise enthalten Distributionen eine Reihe von Patches, die entweder in bestimmte Teile der Funktionsweise der Distribution integriert werden, Backports von Gerätetreibern und Fixes aus neueren, aber unveröffentlichten Versionen des Kernels oder Funktionen, die für ihre Benutzer wegweisend sind.

Wenn Sie Ihren eigenen Kernel kompilieren, haben Sie eine Reihe von Optionen. Sie können einen offiziellen Linus Torvalds-Kernel kompilieren. Dies beinhaltet keine der Patches oder Anpassungen, die von Ihrer Distribution hinzugefügt wurden (die gut oder schlecht sein können) oder Sie können Verwenden Sie Ihr Distribution Rebuild-Tool, um Ihren eigenen Kernel zu erstellen.

Die Gründe, warum Sie Ihren Kernel möglicherweise neu erstellen möchten, sind:

• Patching von Fehlern oder Hinzufügen einer bestimmten Funktion zu einem Produktionssystem, bei dem Sie nicht wirklich das Risiko eingehen können, den gesamten Kernel für ein einzelnes Update oder zwei zu aktualisieren.
• So testen Sie einen bestimmten Gerätetreiber oder eine neue Funktion
• Um den Kernel zu erweitern, arbeiten Sie daran
• Testen einiger "Alpha" -Module oder -Funktionen.

Viele Entwickler verwenden es, um auch benutzerdefinierte Versionen des Kernels für eingebettete Systeme oder Settop-Boxen zu erstellen, für die spezielle Gerätetreiber erforderlich sind, oder um Funktionen zu entfernen, die sie nicht benötigen.

Wenn Sie den Kernel selbst kompilieren, können Sie nur die Teile einbeziehen, die für Ihren Computer relevant sind, wodurch dieser kleiner und möglicherweise schneller wird, insbesondere beim Booten. Generische Kernel müssen so viel Hardware wie möglich unterstützen. Beim Booten erkennen sie, welche Hardware an Ihren Computer angeschlossen ist, und laden die entsprechenden Module. Dies dauert jedoch einige Zeit und sie müssen dynamische Module laden, anstatt den Code direkt in den Kernel einbinden zu müssen. Es gibt keinen Grund, Ihren Kernel 400 verschiedene CPUs unterstützen zu lassen, wenn es nur eine in Ihrem Computer gibt, oder Bluetooth-Mäuse zu unterstützen, wenn Sie keine haben, es ist alles verschwendeter Speicherplatz, den Sie freigeben können

Ich kann nicht glauben, dass die akzeptierte Antwort hier anfängt zu sagen: "Es ist nichts, was Sie tun müssen, um mehr Geschwindigkeit / Speicher / xxx zu erreichen."

Das ist total falsch. Ich erstelle meine Kernels routinemäßig so, dass sowohl nicht benötigter Code entfernt als auch leistungssteigernder Code enthalten ist, der sich hauptsächlich auf Hardware bezieht. Ich verwende zum Beispiel ältere Hardware und kann einige Leistungsverbesserungen erzielen, indem ich selten aktivierte Kerneltreiber wie die HPT36x-Chipsatzunterstützung auf einigen älteren MoBos aktiviere, die über diese integrierte Funktion verfügen.

Ein weiteres Beispiel: BIG SMP unter Slackware ist die Standardeinstellung. Auf einem Dell 2800 wird beispielsweise eine beträchtliche Stellfläche benötigt, um Dinge wie GFSD (nicht als Kernelmodul) auszuführen, die übrigens auch CPU-Ticks für etwas verbrauchen brauche nicht. Ebenso für NFSD und andere Catch-Alls, um alle Mentalitäten zufrieden zu stellen, was in Ordnung ist, wenn Sie nur versuchen, ein Linux auf einer Box zum Laufen zu bringen, sich aber für "speed / memory / xxx whatever" interessieren, dann sind diese Dinge wichtig und funktionieren .

Alle meine Produktionsboxen sind benutzerdefinierte Kernel. Wenn ich auf gängiger Hardware wie Hardware der Dell-Serie (2800, 2850, 2900 usw.) arbeite, ist es ganz einfach, die .config-Datei des Kernels auf jede Box zu kopieren und den Kernel zu kompilieren und zu installieren.

In folgenden Situationen können Sie von der Kompilierung Ihres eigenen Kernels profitieren:

• Ein Kernel mit deaktiviertem Modulladen ist sicherer. Dazu müssen Sie die Module auswählen, von denen Sie wissen, dass Sie sie benötigen, und sie als Teil des Kernels einbeziehen, anstatt sie als Module zu kompilieren.

• Das Deaktivieren der Unterstützung für / dev / kmem oder das Verkrüppeln mit der entsprechenden Compileroption ist eine gute Sache für die Sicherheit. Ich denke, die meisten Distributionen tun dies jetzt standardmäßig.

• Ich bevorzuge es, wenn möglich, keine initrds zu verwenden. Das Anpassen Ihres Kernels an die Hardware, von der er bootet, beseitigt die initrd.

• Manchmal wird eine spätere Kernelversion Funktionen haben, die Sie benötigen, aber dies ist heutzutage sehr selten. Ich erinnere mich, als ich Debian zum ersten Mal verwendete, verwendete es 2.4-Kernel, aber ich brauchte einen 2.6-Kernel für die Unterstützung von udev.

• Das Deaktivieren von Netzwerkprotokollen / -optionen, die Sie nicht benötigen, kann Ihre TCP / IP-Leistung beschleunigen.

• Das Deaktivieren nicht benötigter Optionen verringert den Speicherbedarf des Kernels, was in Umgebungen mit wenig RAM wichtig ist. Wenn Sie ein 256-MB-RAM-System als Router verwenden, hilft dies.

• Ich finde alle "tty" -Geräte in / dev ärgerlich auf Systemen, auf denen ich mich normalerweise nur über seriell oder ssh anmelde.

Wenn Sie Ihren eigenen Kernel kompilieren, können Sie am Kernelentwicklungsprozess teilnehmen. Dies kann beispielsweise durch die Eingabe von PCI / USB-Geräte-IDs für einen vorhandenen Treiber geschehen, der möglicherweise ein neueres Gerät für Sie funktionsfähig macht Kernel-Entwicklung.

Außerdem können Sie Entwicklungskerne auf Ihrer Hardware testen und Feedback geben, wenn Sie Regressionen feststellen. Dies kann für Sie und andere besonders hilfreich sein, wenn Sie eine ungewöhnliche Hardware haben. Wenn Sie auf einen Distribution-Kernel warten, kann es einige Zeit dauern, bis Korrekturen aus Ihren Problemberichten in eine neue Distribution-Kernel-Version gefiltert werden.

Ich persönlich kompiliere auch gerne meine eigenen Kernel, um nur die Hardware zu unterstützen, die ich habe. Wenn Sie einen Distributionskern ausführen und die Ausgabe von betrachten lsmod(8), sehen Sie viele Module, die für Hardware geladen sind, die Sie nicht haben. Dies kann die Modulliste, / proc, / sys und Ihre Protokolle so verschmutzen, dass sie bei der Suche nach etwas im Rauschen versteckt werden können. Sie können auch nicht zu 100% sicher sein, dass diese Module nicht zu einem Problem beitragen, das Sie diagnostizieren möchten.

Die Antwort von I second gabe. (Mein Kommentar ist zu lang, daher poste ich als Antwort).

Sofern Sie keinen hochspezialisierten Zweck haben (z. B. eingebettete Computer, strikte Sicherheitsprofilerstellung), sehe ich keinen praktischen Vorteil darin, Ihren eigenen Kernel zu kompilieren, außer zu sehen, wie er funktioniert. Indem Sie die Optionen methodisch überprüfen und feststellen, wie sie miteinander interagieren, um das System aufzubauen, können Sie besser verstehen, wie Ihr System funktioniert. Es ist erstaunlich, was Sie herausfinden, wenn Sie versuchen, Komponenten zu entfernen, die scheinbar keinen Zweck für die Aufgaben haben, die Sie ausführen möchten.

Seien Sie jedoch gewarnt - warum das Herunterspringen am Kaninchenbau zweifelsohne berauschend ist, wird es mehr Nächte und Wochenenden kosten, als Sie für möglich gehalten haben!

Bei der Arbeit verwenden wir handgerollte Kernel, um nicht in der Baumstruktur befindliche Patches wie vserver und unionfs anzuwenden.

Zu Hause kompiliere ich handgerollte Kernel, um herauszufinden, bei welchem ​​Commit ein Fehler aufgetreten ist. Sobald ich damit fertig bin, werde ich mich wahrscheinlich an einen handgerollten Kernel halten, bis der Fehler in meiner Distribution (Debian) behoben ist. Dann würde ich wieder auf deren Kernel zurückgreifen.

Dieser Thread ist uralt und noch heute gültig, als die Frage gestellt wurde!

Die Antwort lautet: Sie kompilieren den Linux-Kernel Ihrer Wahl nach Ihren Bedürfnissen und Anforderungen.

Viele Szenarien sind gültig:

1. Sie sind Ingenieur und müssen mit Ihrem Build die Leistungs- und Sicherheitsanforderungen / -anforderungen für Ihr System erfüllen. Sie müssen die Kompilierung erneut durchführen, um die angegebenen Kriterien zu erfüllen und / oder zu übertreffen.

2. Sie sind ein normaler Benutzer und haben ein altes System, das Sie so lange wie möglich weiter verwenden möchten. Sie kompilieren das System neu, um Komponenten hinzuzufügen / zu entfernen und Ihr altes System zu optimieren.

3. Sie sind ein normaler Benutzer mit der neuesten schnellsten Hardware und es hat mehr als genug Speicher / RAM. Sie müssen nicht neu kompilieren, können aber trotzdem, wenn Sie mehr über Ihr System erfahren möchten.

4. Sie möchten einfach nur wie ein gewöhnlicher Microsoft- und / oder Mac-Benutzer sein, nicht neu kompilieren und einfach mit den Updates Ihrer Upstream-Distribution fortfahren.

5. Lass die Szenarien kommen :-)

Im Gegensatz zu Mac / Windows-Benutzern bietet Linux die Wahl. Die Wahl, es einfach zu machen oder das System an Ihre Anforderungen anzupassen.

Für die meisten Anwendungen eignen sich generische Kernel für praktisch jede Hardware. Darüber hinaus enthalten sie normalerweise (ed) verteilungsspezifische Patches, sodass das Kompilieren Ihres eigenen Kernels (möglicherweise) Probleme verursachen kann.

Die Resonanz, um Ihren eigenen Kernel zu kompilieren, sind:

• Sie verwenden eine quellbasierte Distribution, sodass es keinen "generischen" Kernel gibt
• Sie sind Kernelentwickler und Sie entwickeln Kernel
• Sie müssen den Kernel beispielsweise für eingebettete Geräte mit sehr begrenzter Festplatte anpassen
• Einige Treiber sind nicht kompiliert (sehr seltener Fall)
• Sie möchten den Kernel patchen UND wissen, was Sie tun
• Sie möchten lernen, wie man einen Kernel kompiliert

Wenn ich keine quellbasierte Distribution verwenden würde, würde ich den Kernel überhaupt nicht kompilieren.

Ein weiterer Fall neben den vielen hier genannten Fällen, in denen benutzerdefinierte Kernel kompiliert wurden, ist die Einrichtung spezieller Netzwerk-Boot-Umgebungen, in denen das Laden von Modulen nicht möglich ist und Sie für bestimmte Aufgaben voll funktionsfähige Kernel an bestimmte Computer weitergeben müssen.

Ich bin überrascht, dass niemand diesen Grund für das Kompilieren eines benutzerdefinierten Kernels erwähnt hat:

weil Sie einen anderen C / c ++ - Compiler verwenden möchten. GCC ist ziemlich gut zum Kompilieren des Linux-Kernels. Aber es gibt weit überlegene Compiler! Die Optimierungen von GCC stehen etwas hinter Intels C / C ++ - Compiler zurück. Und Intel liefert die Performance Primitives-Bibliotheken und das Vtune-Tool, die beide für die Erstellung eines Hochleistungs-Linux-Kernels unverzichtbar sind. Mit GCC und G ++ kommt man nur so weit. Praktisch egal was Sie tun, das Ergebnis wird vom Compiler begrenzt. Ich verwende also den Intel-Compiler und die Leistungsbibliotheken. Der Download ist etwas groß - 1,5 GB, aber das gibt eine Vorstellung davon, was alles in einem guten Compiler enthalten ist.

Der C / C ++ - Compiler von Intel ist für den nichtkommerziellen Gebrauch kostenlos verfügbar. Es ist jedoch einfacher, die nicht-kommerzielle Download-Seite für den Intel C ++ - Compiler zu durchsuchen, um die Website von Intel zu durchsuchen. Normalerweise benutze ich GCC / G ++ für nichts. Und Sie müssen kein Programmierer sein. Sie legen einfach Ihre Umgebung fest und ändern zwei Zeilen in der make-Datei, um auf Intels Compiler zu verweisen.

Dann können Sie eine ernsthafte Geschwindigkeit bekommen!

Wenn Sie Linux auf einer ganz bestimmten Hardware installieren möchten, die exotischer ist als ein DS , müssen Sie Ihren eigenen Kernel crosskompilieren.