[LinuxOB] Linux-Kernel - Marke Selbstgebaut

[Christian Hesse]

On Sunday 04 January 2004 17:26, Daniel Dombrowski wrote:
> On 2004.01.04 16:37, katja pieck wrote:
> > Danke, ich hoffe aber, wenn Ihr Eure Erklärungen anfangt,
> > vielleicht ein wenig vorher? Dann hätte ich vielleicht sogar eine
> > Chance etwas zu verstehen oder mache ich vielleicht doch besser den
> > VHS Kurs?
>
> Ich hatte jetzt auf dem Level angefangen, wo Udo angefangen hatte.
> Natürlich kann ich auch mal ganz bei Null anfangen.
>
> Also:
>
> Der Kernel (http://www.kernel.org/) ist das, was ein Linux eigendlich
> zu einem Linux macht. Auch wenn umganssprachlich (und technisch gesehen
> völlig falsch) oft ganze Distributionen als "Linux" bezeichnet werden
> so ist eigendlich nur der Kernel das, was "Linux" heißt.

Genau genommen ist das minimale Betriebssystem auf Linuxbasis "GNU/Linux", da 
der Kernel noch von den wichtigsten Programmen aus dem GNU-Projekt umgeben 
sein sollte um sinnvoll genutzt werde zu können.

> Der Kernel beinhaltet alle Treiber, die ein System zum Laufen braucht
> und stellt für das Betriebssystem einheitliche Schnittstellen für den
> Zugriff auf die Hardware (und eine ganze Reihe an "Geräten", die nur
> logisch, nicht aber physikalisch vorhanden sind) bereit.

Außerdem ist er für die Speicher- und Prozessverwaltung zuständig.

> Wenn ein Rechner bootet, dann läuft als erstes das BIOS an. Dies ist
> noch eine sehr hardwarenahe und betriebssystemunabhängige
> Angelegenheit. Das BIOS ließt dann den Boot-Sektor des Mediums, von dem
> gebootet werden soll (i.d.R. die Festplatte). Der Boot-Sektor sind die
> ersten 512 Byte der Platte.

-> MBR, Master Boot Record

> Dort befindet sich der sog. Boot-Loader. Im 
> Zusammenhang mit Linux werden hier in der Regel LiLo oder Grub
> eingesetzt. Der Bootloader übergibt dann - sofern entsprechend
> konfiguriert - die Kontrolle an den Linux-Kernel. Sobald der Linux-
> Kernel geladen ist, übergibt dieser die Kontrolle an den init-Prozess,
> welcher dann die weiteren Dienste auf dem Rechner startet.

"Kontrolle übergeben" ist vielleicht das falsche Wort. Die Kontrolle hat 
weiterhin der Kernel, er startet einfach init und lässt diesen Prozess den 
Rechner in den entsprechenden Runlevel booten.

> Die Treiber im Linux-Kernel können auf zwei verschiedene Arten
> eingebunden werden. Zum einen können sie fest in den Kernel
> einkompiliert werden, zum anderen können sie als Module nachgeladen
> werden. Auf jeden Fall in den Kernel einkompiliert werden müssen die
> Dinge, die der Kernel braucht, um essentielle Dinge erledigen zu können
> - z.B. auf die Festplatte zugreifen zu können, die Dateisysteme lesen
> zu können, etc.

Es muss alles das im Kernel sein was gebraucht wird bis zu dem Zeitpunkt, wo 
der Kernel in der Lage ist Module nachzuladen. Das andere war aber schon ganz 
richtig, es geht darum, dass der Kernel bis zum Lesen des root-Dateisystems 
kommen muss.

> Alle weiteren Treiber können entweder fest einkompiliert werden oder
> als Modul nachgeladen werden. Was man letztendlich bevorzugt, kann bis
> in einen Glaubenskrieg ausarten.

Es gibt eigentlich drei Arten von Kernelbauern. Diejenigen, die...

1) so wenig wie möglich in den Kernel bauen, alles wirklich nur das, was bis 
zum Lesen des Dateisystems gebraucht wird.
2) das eincompilieren, was immer gebraucht wird (auch alsa für Sound, ...) 
aber Sachen als Module machen, die man nicht immer braucht (scanner, 
usb-storage, ...)
3) wirklich alles in den Kernel packen, was man mal irgendwann gebrauchen 
kann.

Früher habe ich eher zur dritten Gruppe tendiert, jetzt ziege ich die zweite 
vor.

> Ich persönlich bevorzuge fest 
> einkompilieren, da ich dann immer alles an Board habe. Auf älteren
> Systemen macht es aber durchaus Sinn, nur die Module zu laden, die auch
> gerade wirkich benötigt werden. Damit sind wir auch schon beim größten
> Vorteil der Module angekommen: Module können während des Betriebs Ge-
> oder Entladen werden. Weiterhin werden Treiber, die noch nicht im
> Kernel intergriert sind, sondern von Drittanbietern zur Verfügung
> gestellt werden i.d.R. als Module zur Verfügung gestellt.
>
> Und wie komme ich jetzt an meinen eigenen Kernel?
>
> Erstmal muss man wissen, welche Version man will/braucht. Oben hatte
> ich bereits die Adresse für die "offiziellen" Kernel genannt
> (http://www.kernel.org/). Fast jeder Distributor bietet jedoch auch
> eigene Kernel-Varianten an, die auf die eine oder andere Art verändert
> wurden.
>
> Grundsätzlich gilt aber: Eine Kernel-Versions-Nummer besteht immer aus
> 3 Zahlen, also z.B.:
>
> 2.4.23
>
> Besonders interessant ist hierbei immer die zweite Zahl. Ist diese
> gerade, so handelt es sich um eine als stabil geltende Kernel-Version,
> ist diese ungerade, so sind dies Sourcen, die sich noch in der
> Entwicklung befinden. Gerade am Anfang sollte man sich auf die stabilen
> Sourcen beschränken, außer, man weis, was man tut. Weiterhin gibt es
> noch mögliche Zusätze zu der Versionsnummer. -pre# (prereleases) sind
> immer Vorabversionen zwischen den Versionsnummern, -rc# (release
> candidate) sind potentielle Kandidaten für die nächste Versionsnummer.
> I.d.R. reichen aber die "vollen" Versionsnummern aus, außer, man weis,
> was man tut.

-test# gibt es immer dann, wenn eine neue Kernelreihe vor der stable release 
steht

Außerdem werden von einigen Kernelhackern regelmäßig eigene Patche 
veröffentlicht, hier die bekanntesten:
-ac# Patch von Alan Cox (leider im Moment nicht so aktuell, da dieser in einem 
einjährigen Urlaub ist)
-mm# Patch von Andrew Morton (sehr interessant, da er der Maintainer des 
aktuellen stabilen Kernels ist)
-dj# Patch von Dave Jones
... und viel mehr

Außerdem haben Distributionen oft ihre eigenen Patchsets, so zum Beispiel 
Mandrake mit -mdk#.

> Für die 2.4er-Version ist derzeit 2.4.23 die aktuelle Versionsnummer,
> bei der 2.6er-Version ist es 2.6.0. Über die 2.6er-Version wird
> Christian euch sicherlich noch was erzählen können, ich beschränke mich
> hier jetzt auf den 2.4er.

Ich ergänze wo es erforderlich ist. :)

> Wenn man nun seinen Kernel bauen will, läd man dazu die entsprechenden
> Sourcen herunter. Diese erreicht man über o.g. Website. Anschließend
> entpackt man das Paket. Ich nehme grundsätzlich immer .tar.bz2, weil
> die einfach kleiner sind. 

Ich nehme immer nur die Patche, das ist noch viel kleiner (1-2 MB statt 30 
MB...)

> Die Kernel-Sourcen residieren eigendlich 
> immer in /usr/src/linux-VERSIONSNUMMER. Also das Archiv nach /usr/src
> kopieren und entpacken:
>
> bzcat linux-2.4.23.tar.bz2 | tar x
>
> Dann sollte es dort ein Verzeichnis linux-2.4.23 geben.

Den Symlink nicht vergessen, eine Programme/Pakete erwarten den Kernel 
unter /usr/src/linux/

ln -s linux-VERSIONSNUMMER /usr/src/linux

> Dort hinein und 
>
> make menuconfig
>
> Kurz darauf erscheint das Konfigmenü. Dort muss man alle Dinge
> auswählen, die man im Kernel haben möchte. Auf Details verzichte ich
> jetzt, da diese eigendlich nur individuell zu beantworten sind. Nachdem
> man dort fertig ist und gespeichert hat, gehts weiter mit:
>
> make dep && make clean bzImage modules modules_install

make dep entfällt wie schon gesagt beim 2.6er Kernel.

> Je nach Rechner und Auswahl der Module dauert das ganze Spektakel
> zwischen 5 Minuten und 5 Stunden (OK, gibt natürlich Hardware, wo es
> auch 5 Wochen dauert ...).

In der Anfangszeit von Linux waren die Realeasezeiten der Kernel teilweise 
kürzer als es gedauert hat einen Kernel zu compilieren...
Der Rekord liegt übrigens bei 7,5 Sekunden.

> Der fertige Kernel liegt dann in /usr/src/linux/arch/i386/boot/bzImage.
> Also noch nach /boot kopieren:
>
> cp /usr/src/linux/arch/i386/boot/bzImage /boot

System.map nicht vergessen:

cp /usr/src/linux/System.map /boot

> Dann noch den Bootloader konfigurieren (auch das ist ein eigenes Thema
> für sich, da je nach Bootloader unterschiedlich) und hoffen, dass der
> nächste Reboot klappt. Übrigens sollte man NIE darauf vertrauen, dass
> der Kernel geht, also immer einen bereits getesteten in der Hinterhand
> haben als Rescue-System. :)
>
> Ich denke, man merkt, dass man über das Thema Linux-Kernel ganze Bücher
> voll schreiben kann, ich habe mal einfach versucht, mit auf das
> wichtigste zu Beschränken. Ergänzungen oder Rückfragen sind natürlich
> jederzeit willkommen.

Ergänzt habe ich schon, Rückfragen sind gerne willkommen.

Gruß
  Christian

-- 
 Linux - Damit der Ausmehmefehler nicht zur Regel wird.