1 files changed, 131 insertions, 6 deletions

diff --git a/kernel-devel/kernel-basics/handout_kernel-basics_de.tex b/kernel-devel/kernel-basics/handout_kernel-basics_de.tex
index 4c391b2..057f4bc 100644
--- a/kernel-devel/kernel-basics/handout_kernel-basics_de.tex
+++ b/kernel-devel/kernel-basics/handout_kernel-basics_de.tex
@@ -1,17 +1,142 @@
-\documentclass{article}
+\documentclass{lxarticle}
 \usepackage{german}
 \usepackage[utf8]{inputenc}
+\usepackage{lxheaders}
+\usepackage{lxextras}
 
 \begin{document}
 
-\section*{Titel}
+\section*{Kernel-Grundlagen}
 
-\subsection*{Abschnitt1}
+Der Linux-Kernel ist moderner Betriebssystemkern, der sich unter anderem
+durch folgende Eigenschaften auszeichnet:
 
-Text
+\begin{itemize}
+\item Freie Software (GPL Version 2)
+\item Auf vielen Plattformen lauffähig
+\item Hohe Skalierbarkeit vom Handy bis zum Supercomputer
+\item Große Anzahl integrierter Treiber
+\item Einfache Entwicklung eigener Treiber
+\item Codequalität auf hohem Niveau
+\item Qualitätssicherung durch Code-Review unabhängiger Personen
+\item ca. 10 Millionen Codezeilen (ca. 80\% davon Treiber)
+\item hohes Entwicklungstempo
+\item hervorragende Netzwerk-Fähigkeiten
+\item Echtzeit-Fähigkeit leicht und sauber erreichbar
+\end{itemize}
 
-\subsection*{Abschnitt2}
+Diese Eigenschaften haben dazu geführt, dass im Embedded-Bereich heute die
+große Mehrzahl der neu begonnenen Projekte mit Linux realisiert werden. Aber
+auch in vielen anderen Bereichen wie dem Cluster-Computing (Google, Rendern
+von Spielfilm-Effekten in Hollywood) werden die Aufgaben heute fast
+ausschließlich mit Linux gelöst.
 
-Text
+\subsection*{Aufbau des Kernels}
+
+Der Sourcecode des Kernels ist recht übersichtlich in Subsysteme gegliedert.
+Die Grenzen der einzelnen Subsysteme sind keinesfalls scharf definiert, aber
+trotz einzelner Überlappungen und gegenseitigen Abhängigkeiten ist doch ein
+hohes Mass an Unabhängigkeit erreicht worden. Dies trägt entscheidend zur
+Qualität bei, da Änderungen in einem Bereich andere Subsysteme meist nur
+wenig beeinflussen.
+
+\begin{figure}[h]
+\centering
+\includegraphics[width=0.8\textwidth]{images/Subsystems.png}
+\caption{Kernel-Aufbau aus Subsystemen}
+\label{img:subsystems}
+\end{figure}
+
+Abbildung \ref{img:subsystems} zeigt schematisch diesen Aufbau. Man
+unterscheidet zunächst zwischen Subsystemen des \emph{Kernel-Core} und
+Treiber-Subsystemen. Zum Kernel-Core rechnet man Subsysteme wie den für die
+Prozessumschaltung verantwortlichen Scheduler, Memory-Management, Timer und
+ähnliche Einheiten, die zur grundsätzlichen Funktionalität des Kernel gehören
+und auf allen Plattformen vorhanden sein müssen.
+
+Der weitaus größte Teil des Kernels besteht aus Treibern. Hier kann man
+wiederum unterscheiden zwischen Treibern für Hostcontroller von
+Schnittstellen wie PCI, USB oder I2C und den Treibern für Geräte, die diese
+Schnittstellen benutzen. Abbildung \ref{img:subsystems} deutet an, dass es
+zwischen diesen Treibern durchaus Querverbindungen geben kann. Eine PCI-Karte
+kann ja durchaus einen USB- oder I2C-Hostcontroller enthalten, und ein
+bestimmter Sound-Chip könnte wahlweise per USB oder per PCI angeschlossen
+sein.
+
+Unabhängig von der Art der Schnittstellen gibt es ein Repertoire an
+Funktionen, die alle Treiber benötigen. Dazu gehört etwa die Funktionalität,
+Treiber und Geräte einander zuzuordnen. Auch die Darstellung des
+Treiber-Baums im \cmd{sysfs} kommt automatisch allen Treibern zugute.
+Diese übergeordneten Treiberfunktionen werden als \emph{Driver Core}
+bezeichnet.
+
+\subsection*{Kernel Maintainer}
+
+Jedes Subsystem wird normalerweise von einem, manchmal auch mehreren
+Programmierern betreut. Diese Betreuer bezeichnet man als \emph{Maintainer}.
+Ihre Aufgabe besteht darin, den Code selbst weiter zu entwickeln, und vor
+allem die Erweiterungsvorschläge anderer Entwickler zu prüfen. Sie haben als
+Spezialisten für ein bestimmtes Sachgebiet eine wichtige Aufgabe bei der
+Weiterentwicklung und Qualitätssicherung des Kernels.
+
+Da der Kernel von einer freien Entwicklergemeinde entwickelt wird, haben
+Maintainer natürlich keine Weisungsbefugnisse gegenüber anderen
+Programmierern. Dennoch ist es kaum möglich, eine Änderung, die der
+zuständige Maintainer ablehnt, in den offiziellen Kernel zu bringen. Die
+Programmierer, die sich vor allem mit der Integration der vielen
+Änderungsvorschläge befassen (an der Spitze Linus Torvalds), respektieren
+üblicherweise die Entscheidung der zuständigen Maintainer.
+
+Die Kernel-Maintainer sind in der Datei \cmd{MAINTAINERS} im Hauptverzeichnis
+der Kernelquellen aufgelistet. Dort findet man auch die für das jeweilige
+Thema zuständige Mailingliste. Fragen oder Änderungsvorschläge sollte man
+\emph{immer} an die Mailingliste senden und nicht persönlich an den
+Maintainer!
+
+\subsection*{Entwicklungsprozess}
+
+Änderungen am Linux-Kernel erfolgen ausschließlich durch \emph{Patche}. Ein
+Patch ist eine durch das Programm \cmd{diff} Textdatei, die die Änderungen
+durch Angabe der entfernten beziehungsweise hinzugefügten Zeilen beschreibt.
+Das verwendete Textformat ist sehr gut lesbar und ermöglicht ein schnelles
+Erkennen der vorgenommenen Änderungen.
+
+Wer eine Änderung in den offiziellen Kernel bringen möchte, generiert
+zunächst einen solchen Patch. Dann sendet er den Patch in einer Mail an die
+zuständige Mailingliste und nimmt dabei den oder die zuständigen Maintainer
+in Cc:, zusätzlich eventuell weitere Autoren von betroffenem Quellcode. Meist
+erhält er dann innerhalb kurzer Zeit Antworten mit Reviews seines Patch. Je
+nachdem, wie diese ausfallen, wird er seine Änderungen noch einmal
+überarbeiten und erneut einsenden. 
+ 
+Für Änderungen am Kernel-Code gelten sehr strenge Richtlinien für den
+\emph{Coding Style}, das Erzeugen und Versenden des Patch sowie das
+Verhalten auf Mailinglisten. Grundsätzlich sollte der Anbieter eines Patch
+in der Lage sein, mit rein technischen Argumenten zu erläutern, warum es eine
+Verbesserung darstellt, den Patch aufzunehmen.
+
+Informationen dazu findet man in den Kernelquellen unter
+
+\cmd{Documentation/CodingStyle}
+
+\cmd{Documentation/SubmittingPatches}
+
+\subsection*{Kernel-Konfiguration}
+
+Der Kernel ist durch eine Vielzahl an Optionen (mehrere 1000) in weiten
+Bereichen konfigurierbar. Die Konfiguration wird im Hauptverzeichnis der
+Kernelquellen in der versteckten Datei \cmd{.config} gespeichert. Diese Datei
+wird normalerweise nicht von Hand editiert, sondern menügesteuert mit Hilfe
+eines integrierten Konfigurationstools, das man mit \cmd{make menuconfig}
+aufruft.
+
+Diese Tool bezieht seine Informationen aus Dateien mit dem Namen
+\cmd{Kconfig}, die sich in jedem Unterverzeichnis des Quellcodebaums befinden.
+Diese Dateien enthalten die Bezeichnung der Option und die zugehörigen
+Abhängigkeiten und Hilfetexte.
+
+Das Kernel-Buildsystem stellt ein eigenes Subsystem dar und hat einen eigenen
+Maintainer. Es handhabt den kompletten Build-Prozess des Kernels und
+unterstützt dabei auch explizit Cross-Compiling.
 
 \end{document}