# Kernel Konfiguration - was aktivieren?



## exitboy (14. August 2008)

Hallo,

ich habe nun schon oefter einen Kernel gebaut, auch schon einige Probleme damit geloest. Nun moechte ich mich mal an was Groesseres machen und einen Kernel erstellen, der genau auf meinen Rechner zugeschnitten ist, aber auch wirklich nicht mehr beinhaltet.

Ich hab mir mal ne Live CD geschnappt um im /proc Verzeichnis meine Geraete zu ermitteln. Soweit so gut ... leider hab ich jetzt etwas Probleme diese Listen in die Kernel Konfiguration umzusetzen.
*
Wie koennt Ihr mir helfen?*

1. Gibt es irgendwelche Listen (essentials), wo ich nachlesen kann, was zwingend an built-ins im Kernel enthalten sein muss?

2. Woher nehme ich tieferes Detailwissen zum Innenleben meines PCs? Ich muss zugeben, dass ich nicht wirklich der Hardwareexperte bin. (North/Southbridge und Co sagen mir schon was, aber was jetzt z.B. MTRR/NUMA,MCE Features angehen ... da bin ich ueberfragt.) Koennte auch alles Nachgooglen, natuerlich, nur es geht doch bestimmt auch einfacher, oder?

3. Brauche ich das Wissen ueberhaupt zwingend? Oder gibt es Scripte die mir zusammentragen, was ich fuer Hardware im Rechner habe (hier HP Laptop DV6000) und welche Module ich selektieren soll? 

4. Wie geht Ihr bei einem Kernelbau mit den Modulen/Inbuilds vor?

5. Mein letzter Kernelbau hat 2h gedauert. Ist das normal? War aber auch fast alles inkludiert.

Besten Dank fuer Eure Hilfe


----------



## Navy (14. August 2008)

exitboy hat gesagt.:


> 1. Gibt es irgendwelche Listen (essentials), wo ich nachlesen kann, was zwingend an built-ins im Kernel enthalten sein muss?



Eine solche generelle Liste wird es wohl nicht geben (wenn doch, dann immer her damit), da der Linuxkernel ja auf vielen verschiedenen Architekturen mit teilweise grundsätzlich verschiedener Hardware läuft.



> 2. Woher nehme ich tieferes Detailwissen zum Innenleben meines PCs? Ich muss zugeben, dass ich nicht wirklich der Hardwareexperte bin. (North/Southbridge und Co sagen mir schon was, aber was jetzt z.B. MTRR/NUMA,MCE Features angehen ... da bin ich ueberfragt.) Koennte auch alles Nachgooglen, natuerlich, nur es geht doch bestimmt auch einfacher, oder?



Das Script "hwinfo" sollte Dir helfen.



> 3. Brauche ich das Wissen ueberhaupt zwingend? Oder gibt es Scripte die mir zusammentragen, was ich fuer Hardware im Rechner habe (hier HP Laptop DV6000) und welche Module ich selektieren soll?



Vor Jahren gab es mal die Idee einer automatischen Kernelkonfiguration
http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-09/1319.html

Problem hierbei war aber, dass Durch Veränderungen des Kernels das Script jedesmal hätte angepasst werden müssen. Ob die Entwicklung noch lebt wage ich zu bezweiflen und vom Einsatz des Scriptes rate ich ab.



> 4. Wie geht Ihr bei einem Kernelbau mit den Modulen/Inbuilds vor?



Modular. So oft es geht. Ich halte es da eher mit Tanenbaum und dem Microkernel (jajajaja, ich weiß, dass Linux kein solcher ist)



> 5. Mein letzter Kernelbau hat 2h gedauert. Ist das normal? War aber auch fast alles inkludiert.



Du kannst auch auf schnelleren Systemen cross-compilieren, wenn Dir solche zur Verfügung stehen. Zudem skaliert das Compilieren hervorragend, wenn Du also mehrere Prozessoren oder Kerne hast, dann nutze dies. 2 Stunden halte ich für arg viel, allerdings ist es auch schon ein paar Jahre her, dass ich dieses selber gemacht habe


----------



## exitboy (14. August 2008)

perfekt, danke.


----------



## exitboy (14. August 2008)

Folgende Fragen sind gerade noch aufgekommen:

6. Wozu laed man sich eigentlich einen neuen Kernel runter? 
Werden da Sicherheitspatches hinzugefuegt, je hoeher die Version wird, oder geht es primaer um inhaltliche Aenderungen?
... weil dann kaeme die Frage auf, warum einige Leute bevorzugt aeltere Kernels nutzen.

7. Hatte mal das Problem dass ne GraKa nicht lieft, sondern nur mit nem bestimmten Kernel (in Verbindung mit Envy -->Softwarebedingt).
Was mache ich wenn ein Hardwareteil nicht mit Kernel xy funkzt, dafuer mit einer anderen Version, welche jedoch wiederrum ein anderes Element nicht unterstuezt. Kann ich Kernels mischen?

8. Was hat es mit einem Kernelpatches auf sich, die ich bei Kernel.org runterladen kann. Bisher habe ich immer den Kernel neukompiliert. Was bringen die mir fuer Vorteile?

9. Habe ich es richtig verstanden, dass ich einen Kernel wenn ich diesen klein haben moechte, nur auf einen speziellen Rechner anpassen kann und wenn ich diesen fuer mehrere Systeme nutzen will, muss dieser mehrere Elemente beinhalten.

10. Wie geht Ihr mit den Modulen um. Ich nutze Module ausschiesslich fuer Anforderungen, die ich nicht taeglich habe, z.B: SD Kartenverwendung (kommt bei mir ca. 1 mal im Jahr vor [rein illustrativer Natur fuer das Beispiel jetzt]. Sonst muesste ich ja etliche Module einladen.

11. Ist modprobe ndiswrapper auch zu vergleichen mit einem kernel modul einladen. ... weil dieses doch eigentlich nicht aus dem Kernel kommt ... .

12. Wie lade ich Kernelmodule zur Laufzeit ein?

Besten Dank


----------



## Navy (14. August 2008)

exitboy hat gesagt.:


> 6. Wozu laed man sich eigentlich einen neuen Kernel runter?
> Werden da Sicherheitspatches hinzugefuegt, je hoeher die Version wird, oder geht es primaer um inhaltliche Aenderungen?
> ... weil dann kaeme die Frage auf, warum einige Leute bevorzugt aeltere Kernels nutzen.



Die neueren Kernel bringen jeweils eine Menge an Änderungen mit sich, die teilweise Hardwareunterstützung betreffen, andererseits aber auch Performance, Stabilität, Timing beeinflußen und/oder verändern. Neue Ideen werden eingebracht, alte und obsolete Teile verworfen. Dabei kommen sich die Entwickler mit ihren Ansichten und Philosophien gegenseitig sehr oft in die Quere.

Ältere Kernel werden eingesetzt, weil der neue Kernel so viele Änderungen mit sich bringt, dass ein komplettes Redesign der Konfiguration älterer Gerätes nötig wäre. Das betrifft z.B. das Routing oder aber das Ansprechen der Festplatten. Gründe gibt es viele, manche berechtigt, andere philosophisch oder engstirnig begründet.



> 7. Hatte mal das Problem dass ne GraKa nicht lieft, sondern nur mit nem bestimmten Kernel (in Verbindung mit Envy -->Softwarebedingt).
> Was mache ich wenn ein Hardwareteil nicht mit Kernel xy funkzt, dafuer mit einer anderen Version, welche jedoch wiederrum ein anderes Element nicht unterstuezt. Kann ich Kernels mischen?



Generell sollte das eigentlich nicht vorkommen. Im Detail kann es schon mal vorkommen, das proprietäre Treiber für ältere Hardware nicht mit neueren Kernel zu Recht kommen, in den älteren Kernel aber die neue Hardware nicht läuft. Dann kann man eigentlich nur auf einen Backport der neuen Treiber hoffen oder aber die alte Hardware anderweitig verwenden.
Wenn Du bewandert in POSIX und der LINUX-API im allgemeinen bist, dann kannst Du versuchen das beste beider Kernelvarianten zu vereinen. Zum einen wirst Du Dich ganz schön verbiegen müssen und zum anderen seeeeeehr viel Zeit investieren für etwas, was möglicherweise keine Zukunft hat. Interessant wäre dann http://www.linuxfoundation.org/en/Driver_Backport_Charter für Dich.



> 8. Was hat es mit einem Kernelpatches auf sich, die ich bei Kernel.org runterladen kann. Bisher habe ich immer den Kernel neukompiliert. Was bringen die mir fuer Vorteile?



Kernelpatches sind kleiner. Du musst dann nicht mehr das gesamte Kernelpaket runterladen.



> 9. Habe ich es richtig verstanden, dass ich einen Kernel wenn ich diesen klein haben moechte, nur auf einen speziellen Rechner anpassen kann und wenn ich diesen fuer mehrere Systeme nutzen will, muss dieser mehrere Elemente beinhalten.



Ja. Entweder komplierst Du für genau Dein (und identische) Systeme, oder aber generisch für andere -- architekturidentische -- Systeme



> 10. Wie geht Ihr mit den Modulen um. Ich nutze Module ausschiesslich fuer Anforderungen, die ich nicht taeglich habe, z.B: SD Kartenverwendung (kommt bei mir ca. 1 mal im Jahr vor [rein illustrativer Natur fuer das Beispiel jetzt]. Sonst muesste ich ja etliche Module einladen.



Module werden dynamisch geladen, wenn sie gebraucht werden. Dafür sorgt der Kernel. Für das mounten von Datenträgern von Kartenlesern ist u.A. auch udev verantwortlich.



> 11. Ist modprobe ndiswrapper auch zu vergleichen mit einem kernel modul einladen. ... weil dieses doch eigentlich nicht aus dem Kernel kommt ... .



Module müssen nicht in den Kernelsouren beinhaltet sein. Das ermöglicht es auch fremde und proprietäre Treiber zu verwenden die nicht vom Kernelentwicklerteam kommen. Das ist auch einer der wichtigsten Vorteile von Modulen: Sie sind austauschbar und müssen nur gegen den jeweiligen Kernel laufen können.



> 12. Wie lade ich Kernelmodule zur Laufzeit ein?



Hast Du doch schon verwendet:

```
modprobe
```


----------



## Raubkopierer (14. August 2008)

Welche Linux-Distribution nutzt du überhaupt und warum genau baust du dir deinen Kernel selbst? Ich nehme einfach mal du nutzt ein Debian bzw. Ubuntu wenn du schon envy erwähnst. Welches Problem hattest du genau mit deinem Treiber und was für eine Karte nutzt du?

Und nun zu deinen Fragen:



> 4. Wie geht Ihr bei einem Kernelbau mit den Modulen/Inbuilds vor?



Im Prinzip geht man so vor, dass man alles, was an Treibern und Features zum booten oder ständig im Betrieb benötigt wird fest in den Kernel einbindet. Dinge die man nun sehr selten (oder gar nicht benötigt aber auf einem anderen PC auf dem man den Kernel verwenden will) als Modul. Einige binden z.B. Alsa als Modul ein um den Bootvorgang zu beschleunigen.



> 5. Mein letzter Kernelbau hat 2h gedauert. Ist das normal? War aber auch fast alles inkludiert.



das kommt ganz drauf an wie deine leistungsstark deine CPU ist und deine Kompileroptionen gesetzt sind (Architektur, Anzahl der Threads [ ausführliche Lektüre: man make.conf ]). Auch spielt es wie du anmerktest eine Rolle wieviel man einbindet. Bei mir dauert ein Kernel nur ein paar Minuten.



> 6. Wozu laed man sich eigentlich einen neuen Kernel runter?
> Werden da Sicherheitspatches hinzugefuegt, je hoeher die Version wird, oder geht es primaer um inhaltliche Aenderungen?
> ... weil dann kaeme die Frage auf, warum einige Leute bevorzugt aeltere Kernels nutzen.



Es kommen sowohl Sicherheitspatchs und auch neue Features hinzu. Wobei die Features hier der Hauptteil sein dürften. Ältere Kernel kann man ja auch entsprechend patchen. Diese werden wohl primär verwendet, da sie stabil sind. In Distributionen sind die Kernel aber meist 'veraltet' da der Kernel nur in der neuen Version aktuallisiert wird und wischen den Releases liegen i.d.R. einige Monate.



> 7. Hatte mal das Problem dass ne GraKa nicht lieft, sondern nur mit nem bestimmten Kernel (in Verbindung mit Envy -->Softwarebedingt).
> Was mache ich wenn ein Hardwareteil nicht mit Kernel xy funkzt, dafuer mit einer anderen Version, welche jedoch wiederrum ein anderes Element nicht unterstuezt. Kann ich Kernels mischen?



Das ist Unsinn. Das liegt im Endeffekt wahrscheinlich einfach daran, dass du die falschen Kernelheaders für deinen (nvidia?)-Treiber installiert hattest. Würde zumindestens ich meinen. Meiner Meinung ist die Wahrscheinlichkeit, dass etwas mit einem alten Kernel klappt und einem neuen, stabilen Kernel dann nicht mehr relativ gering. Sollte es doch so sein: file a bug report.



> 8. Was hat es mit einem Kernelpatches auf sich, die ich bei Kernel.org runterladen kann. Bisher habe ich immer den Kernel neukompiliert. Was bringen die mir fuer Vorteile?



Weniger Dauer des kompilierens. Kp ... ich nutze immer die Gentoo-Kernelquellen 



> 9. Habe ich es richtig verstanden, dass ich einen Kernel wenn ich diesen klein haben moechte, nur auf einen speziellen Rechner anpassen kann und wenn ich diesen fuer mehrere Systeme nutzen will, muss dieser mehrere Elemente beinhalten.



Im Prinzip hast du Recht. Allerdings nutzt man dafür Module. So handeln auch Distributionen ihre Kernel: Nahezu alles ist als Modul enthalten was den Kernel selbst nicht größer macht aber hochgradig kompatibel da jedes Modul wenn es gebraucht wird hinzugeladen werden kann.



> 10. Wie geht Ihr mit den Modulen um. Ich nutze Module ausschiesslich fuer Anforderungen, die ich nicht taeglich habe, z.B: SD Kartenverwendung (kommt bei mir ca. 1 mal im Jahr vor [rein illustrativer Natur fuer das Beispiel jetzt]. Sonst muesste ich ja etliche Module einladen.



Soviel Speicher nimmt ein einzelnes Modul nun auch nicht ein. Aber der Kernel lädt (sofern er entsprechend konfiguriert ist) automatisch die nötigen Module.



> 11. Ist modprobe ndiswrapper auch zu vergleichen mit einem kernel modul einladen. ... weil dieses doch eigentlich nicht aus dem Kernel kommt ... .



modprobe *ist* der Befehl um Kernelmodule einzuladen. Und das ndiswrapper-Modul *ist* ein Modul für den Kernel auch wenn ndiswrapper kein Teil des selbigen ist.



> 12. Wie lade ich Kernelmodule zur Laufzeit ein?



Siehe Nummer 11 und man modprobe


----------



## Navy (14. August 2008)

> Es kommen sowohl Sicherheitspatchs und auch neue Features hinzu. Wobei die Features hier der Hauptteil sein dürften. Ältere Kernel kann man ja auch entsprechend patchen. Diese werden wohl primär verwendet, da sie stabil sind. In Distributionen sind die Kernel aber meist 'veraltet' da der Kernel nur in der neuen Version aktuallisiert wird und wischen den Releases liegen i.d.R. einige Monate



Zwischen den Releases liegen mitnichten Monate. Teilweise liegen nur 5 Tage zwischen 2 Releases. Du meinst vieleicht Major-releases (Soweit man die so nennen darf)



> Das ist Unsinn. Das liegt im Endeffekt wahrscheinlich einfach daran, dass du die falschen Kernelheaders für deinen (nvidia?)-Treiber installiert hattest. Würde zumindestens ich meinen. Meiner Meinung ist die Wahrscheinlichkeit, dass etwas mit einem alten Kernel klappt und einem neuen, stabilen Kernel dann nicht mehr relativ gering. Sollte es doch so sein: file a bug report.



Es ist kein Unsinn. Natürlich gibt es Treiber-binaries in Form von Modulen, die nicht unter 2.6.x laufen, sehr wohl aber unter 2.4.x oder gar 2.2.x. Die Kernel unterscheiden sich teilweise so stark, dass bei vielen alten Geräten ein Neuentwurf von Treibern nötig gewsen wäre, das aber aus verschiedenen Gründen verworfen worden ist. Im Industriebereich ist das z.B. gar nicht so selten, aus diesem Grund laufen da auch noch 2.2/2.4 Kernel -- mit einer teilweise wahnsinnig hohen uptime.



> Weniger Dauer des kompilierens. Kp ... ich nutze immer die Gentoo-Kernelquellen


Das hingegen ist Unsinn. Warum sollte ein Patch -- der ja sie Sourcen verändert, nicht die Binaries -- das kompilieren merkbar beeinflußen?



> Im Prinzip hast du Recht. Allerdings nutzt man dafür Module. So handeln auch Distributionen ihre Kernel: Nahezu alles ist als Modul enthalten was den Kernel selbst nicht größer macht aber hochgradig kompatibel da jedes Modul wenn es gebraucht wird hinzugeladen werden kann.



Viele Distributionen nutzen gar nicht so viele Module. Einiges wird fest einkompliert da es eh gebraucht wird und das dynamische Laden der Module eher verlangsamend ist.


----------



## exitboy (14. August 2008)

Zum Kernelkompilieren kam ich aus persoenlichem Interresse.
Ich nutze Debian mit gdm. *buntu ist mir irgendie zu interfacig 

Nebenbei hab ich schon seit ewigkeiten Probleme mein dv6000 Laptop mit ner GeForce 6150 Go mit 3D Unterstuetzung zum Laufen zu bekommen. Hab da schon recht viel durch, von den Herstellertreibern, ueber envy hat nichts geholfen.

Hab mir letztens einfach zum Selbststudium mal nen 2.6.26er Kernel gezogen und den auf Debian kompiliert. Zum Testen hab ich menuconfig erstmal mit so allem was mir irgendwie sinnvoll schien gestartet (arbeite mich in das thema aktuell ein), Kernel bootete in ner kernel panic --> hatte SerialATA irgendwie uebersehen. Dann beim zweiten Versuch funkzte es.

Folglich kam ich auf den Gedankengang, vielleicht liegt es ja am Kernel ...

Zurueck zu Envy.: Hier habe ich darauf hin mit dem Entwickler gemailt und erfahren, dass das i mit 2.6.26.1 nicht laufe und ich die 2.6.24 nehmen solle.
Daher die ganzen Verstaendnisfragen. Das hat mich etwas irritiert.


----------



## Dennis Wronka (14. August 2008)

exitboy hat gesagt.:


> 1. Gibt es irgendwelche Listen (essentials), wo ich nachlesen kann, was zwingend an built-ins im Kernel enthalten sein muss?


Ich hab des Oefteren schon darueber nachgedacht ein Kernel-Compile-Tutorial zu schreiben. Bislang hab ich nie den Mut aufgebracht und werde wahrscheinlich auch nie dazu kommen.
Kurz gesagt: Der Kernel ist ein Monster, und die Unterschiede bei der User-Hardware machen es mehr oder weniger unmoeglich ein Tutorial zu schreiben was allgemein gueltig ist.



exitboy hat gesagt.:


> 2. Woher nehme ich tieferes Detailwissen zum Innenleben meines PCs? Ich muss zugeben, dass ich nicht wirklich der Hardwareexperte bin. (North/Southbridge und Co sagen mir schon was, aber was jetzt z.B. MTRR/NUMA,MCE Features angehen ... da bin ich ueberfragt.) Koennte auch alles Nachgooglen, natuerlich, nur es geht doch bestimmt auch einfacher, oder?


Die meisten noetigen Hardware-Informationen bekommst Du von lspci.
Prozessorfeatures findest Du in /proc/cpuinfo, NUMA duerfte auf Heimcomputern wahrscheinlich ein Fremdwort sein.
Allgemein ist die Kernel-Dokumentation auch nicht schlecht, und teilweise sogar richtig hilfreich.



exitboy hat gesagt.:


> 4. Wie geht Ihr bei einem Kernelbau mit den Modulen/Inbuilds vor?


Ich hab frueher statische Kernel gebaut, da ich meine Hardware eigentlich immer in vollem Umfang nutze. Aktuelle Distributionen laden die Module der vorhandenen Hardware eh beim Booten und nicht erst bei Bedarf, sodass der statische Kernel hier Performancevorteile bietet.



exitboy hat gesagt.:


> 5. Mein letzter Kernelbau hat 2h gedauert. Ist das normal? War aber auch fast alles inkludiert.


Das ist wirklich Wahnsinn. Ich hab vor einer Weile mal einen Kernel mit der Fedora-Konfiguration gebaut und der hat sehr lang gebraucht (hab aber nicht gecheckt wie lang genau). Auf meinem alten Athlon XP 3000+ hat ein fuer den Rechner eingestellter Kernel ca. 15 Minuten gebraucht.



exitboy hat gesagt.:


> 6. Wozu laed man sich eigentlich einen neuen Kernel runter?
> Werden da Sicherheitspatches hinzugefuegt, je hoeher die Version wird, oder geht es primaer um inhaltliche Aenderungen?


Sicherheitspatches, neue Treiber, Verbesserungen in Subsystemen...
Seit Kernel 2.6 tut sich viel im "stabilen" Kernel. Mehr als noch unter 2.2 und 2.4 der Fall waren, was wahrscheinlich auch der Grund ist warum wir noch nicht bei 2.8 sind. 

Sicherheitspatches werden oft auch fuer aeltere Kernel nachgereicht. Ausserdem bieten sich diese zum Teil, aufgrund ihrer geringeren Groesse, auf Embedded Systemen an.



exitboy hat gesagt.:


> 8. Was hat es mit einem Kernelpatches auf sich, die ich bei Kernel.org runterladen kann. Bisher habe ich immer den Kernel neukompiliert. Was bringen die mir fuer Vorteile?


Die Kernel-Patches sind lediglich Source-Patches. Neu kompilieren musst Du trotzdem. Der Vorteil ist dass Du einen kleineren Download hast da Du nur das Changeset runterlaedst.
Richtige Kernel-Patches werden mit ksplice moeglich, wo wohl Teile des Kernels (oder eventuell gar der ganze?) im Betrieb ausgetauscht werden kann.
Hab noch nicht sehr viel darueber gelesen, hoert sich aber interessant an.



exitboy hat gesagt.:


> 9. Habe ich es richtig verstanden, dass ich einen Kernel wenn ich diesen klein haben moechte, nur auf einen speziellen Rechner anpassen kann und wenn ich diesen fuer mehrere Systeme nutzen will, muss dieser mehrere Elemente beinhalten.


Richtig, wenn Du einen kleinen Kernel haben willst dann pack nur rein was Du fuer Dein System brauchst. Das kann dann natuerlich heissen dass er auf einem anderen Rechner nicht booten kann, selbst wenn dieser z.B. die selbe CPU hat. Grund dafuer kann dann z.B. sein dass der Treiber fuer den Festplattencontroller nicht mit drin ist.



exitboy hat gesagt.:


> 11. Ist modprobe ndiswrapper auch zu vergleichen mit einem kernel modul einladen. ... weil dieses doch eigentlich nicht aus dem Kernel kommt ... .


NDISWrapper bringt ein Kernelmodul mit. Es ist zwar nicht Bestandteil des Kernels, aber es ist ein echtes Kernelmodul, genauso wie das Kernelmodul des fglrx-Treibers von ATI/AMD.



Navy hat gesagt.:


> Zwischen den Releases liegen mitnichten Monate. Teilweise liegen nur 5 Tage zwischen 2 Releases.


Bei einem frueher 2.6er Kernel (ich glaube es war 2.6.9 oder 2.6.10) hab ich es erlebt das an einem Tag zwei Mikro-Versionen (z.B. von 2.6.10.10 auf 2.6.10.11) kamen. Dieser Kernel (wie gesagt, ich weiss nicht mehr welches Version genau) war extremst aktiv und wurde sehr haeufig aktualisiert.


----------



## exitboy (14. August 2008)

Wo du es grade ansprichst, gibt es nen Tool/Script, dass mir direkt ne Message sendet, wenn auf ner bestimmte Seite neuen Inhalt bietet: z.B. nen neuen Kernel?

Waere doch auch mal was, wenn man schnelle Infos braucht.


----------



## Navy (14. August 2008)

Schreib Dich in die Mailingliste von http://kernel.org ein und filtere auf die Releasemeldungen.


----------



## Raubkopierer (14. August 2008)

navy hat gesagt.:
			
		

> Zwischen den Releases liegen mitnichten Monate. Teilweise liegen nur 5 Tage zwischen 2 Releases. Du meinst vieleicht Major-releases (Soweit man die so nennen darf)



Ich meinte die Releases der Distributionen und nicht die des Kernels. Die begründet in Sicherheitspatches etc. natürlich recht dicht beieinander liegen.

Natürlich gibt es Features, die unter jedem System benötigt werden und die fest eingebunden sind. Doch jeden einzelnen Lan-Treiber in den Kernel zu kompilieren um ihn möglichst kompatibel zu machen ist einfach nicht praktikabel. Also sind solche Treiber oft als Module vorhanden und werden nur bei bedarf genutzt um eine breite Palette an Hardware unterstützen zu können.


----------



## Navy (15. August 2008)

Raubkopierer hat gesagt.:


> Ich meinte die Releases der Distributionen und nicht die des Kernels. Die begründet in Sicherheitspatches etc. natürlich recht dicht beieinander liegen.



Was genau haben die Releasezeiten des Kernels mit den Releasezeiten der Distributionen gemein? Zumal hier ja erster selber kompiliert werden soll...



> Natürlich gibt es Features, die unter jedem System benötigt werden und die fest eingebunden sind. Doch jeden einzelnen Lan-Treiber in den Kernel zu kompilieren um ihn möglichst kompatibel zu machen ist einfach nicht praktikabel. Also sind solche Treiber oft als Module vorhanden und werden nur bei bedarf genutzt um eine breite Palette an Hardware unterstützen zu können.



Danke für diese Einführung in Modularitätstrategien bei Linux. Ich denke jedoch, dass ich hinreichend weiß, welche Teile des Kernels modular vorliegen und welche fest integiert sein sollten. Das bringt die Arbeit so mit sich...


----------



## Raubkopierer (15. August 2008)

Kann es sein, dass du dir von mir etwas auf den Schlips getreten fühlst? Lies doch bitte noch einmal in welchem Zusammenhang ich die Releasezyklen geäußert habe und frage dich dann ob das ganze an dich gerichtet war. Das du dich gut auskennst sieht man ja zur Genüge wenn man ein paar Beiträge von dir liest 

Trotzdem ist es unnötig in meiner Meinung nach korrekte Sätze Fehler reininterpretieren zu müssen und sich dann auch noch leicht beleidigt zu fühlen. Bisschen kindisch


----------

