Merge branch 'master' of ssh://tglx.de/home/linutronix/git/schulung

16 files changed, 788 insertions, 36 deletions

diff --git a/kernel-devel/Makefile b/kernel-devel/Makefile
new file mode 100644
index 0000000..f325edd
--- /dev/null
+++ b/kernel-devel/Makefile
@@ -0,0 +1,6 @@
+SUBDIRS = char-device driver-basics kernel-basics kernel-best-practices kernel-build uio-driver
+
+all clean:
+	for dir in $(SUBDIRS) ; do \
+		(cd $$dir && make $@); \
+	done
diff --git a/kernel-devel/kernel-basics/Makefile b/kernel-devel/kernel-basics/Makefile
new file mode 100644
index 0000000..aad5bb5
--- /dev/null
+++ b/kernel-devel/kernel-basics/Makefile
@@ -0,0 +1,9 @@
+all:
+	pdflatex pres_kernel-basics_de.tex
+	pdflatex hints_kernel-basics_de.tex
+	pdflatex handout_kernel-basics_de.tex
+	pdflatex handout_kernel-basics_de.tex
+
+clean:
+	rm -f *.aux *.log *.pdf *.log *.snm *.toc *.vrb *.nav *.out
+
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}
diff --git a/kernel-devel/kernel-basics/pres_kernel-basics_de.tex b/kernel-devel/kernel-basics/pres_kernel-basics_de.tex
index 07db328..8b6161e 100644
--- a/kernel-devel/kernel-basics/pres_kernel-basics_de.tex
+++ b/kernel-devel/kernel-basics/pres_kernel-basics_de.tex
@@ -1,24 +1,103 @@
-\documentclass{article}
+\documentclass{beamer}
+\usetheme{linutronix}
 \usepackage{german}
 \usepackage[utf8]{inputenc}
+\usepackage{pgf}
+\usepackage{graphicx}
+\usepackage{lxextras}
+
+\title{Kernel-Grundlagen}
+\institute{Linutronix GmbH}
 
 \begin{document}
 
-\section*{Block \lq Was ist Linux?\rq}
+\maketitle
+
 
-\subsection*{Lernziele}
+% ----- Slide ------------------
+\begin{frame}
+\frametitle{Kernel-Eigenschaften}
 \begin{itemize}
-\item Lernziel 1
-\item Lernziel 2
-\item Lernziel 3
+\item Freie Software (GPL Version 2)
+\pause
+\item Auf vielen Plattformen lauffähig
+\pause
+\item Hohe Skalierbarkeit vom Handy bis zum Supercomputer
+\pause
+\item Große Anzahl integrierter Treiber
+\pause
+\item Einfache Entwicklung eigener Treiber
+\pause
+\item Codequalität auf hohem Niveau
+\pause
+\item Qualitätssicherung durch Code-Review unabhängiger Personen
+\pause
+\item ca. 10 Millionen Codezeilen (ca. 80\% davon Treiber)
+\pause
+\item hohes Entwicklungstempo
+\pause
+\item hervorragende Netzwerk-Fähigkeiten
+\pause
+\item Echtzeit-Fähigkeit leicht und sauber erreichbar
 \end{itemize}
+\end{frame}
 
-\subsection*{Unterrichts-Ablauf}
+% ----- Slide ------------------
+\begin{frame}
+\frametitle{Aufbau des Kernels}
+\centering
+\includegraphics[width=0.8\textwidth]{images/Subsystems.png}
+\end{frame}
 
-Hinweise zur Präsentation, Zeitplanung, etc.
+% ----- Slide ------------------
+\begin{frame}
+\frametitle{Kernel Maintainer}
+\begin{itemize}
+\item Betreuer eines Subsystems oder Treibers
+\pause
+\item Verantwortlich für Weiterentwicklung
+\pause
+\item Review von Änderungsvorschlägen
+\pause
+\item Annehmen/Ablehnen von Änderungsvorschlägen
+\pause
+\item Weitergabe/Verwaltung angenommener Änderungen
+\end{itemize}
+\end{frame}
 
-\subsection*{Übungen bei vorhandener Hardware}
+% ----- Slide ------------------
+\begin{frame}
+\frametitle{Entwicklungsprozess}
+\begin{itemize}
+\item Änderungsvorschläge in Form von Patchen
+\pause
+\item Review und Diskussion auf Mailinglisten
+\pause
+\item strenge Richtlinien für Coding Style
+\pause
+\item strenge Richtlinien für Form und Weitergabe von Patchen
+\pause
+\item Nur technische Argumente zählen!
+\end{itemize}
+\end{frame}
+
+% ----- Slide ------------------
+\begin{frame}
+\frametitle{Kernel-Konfiguration}
+\begin{itemize}
+\item Grosse Zahl von Konfigurations-Optionen
+\pause
+\item Speicherung in \cmd{.config}
+\pause
+\item Ändern der Konfiguration: \cmd{make menuconfig}
+\pause
+\item Informationen über Optionen in \cmd{Kconfig}-Dateien
+\pause
+\item Kernel-Buildsystem: Eigenes Subsystem mit eigenem Maintainer
+\pause
+\item Unterstützt explizit auch Cross-Compiling
+\end{itemize}
+\end{frame}
 
-Hinweise zu Übungen, Zeitlimit dazu.
 
 \end{document}
diff --git a/kernel-devel/kernel-build/Makefile b/kernel-devel/kernel-build/Makefile
new file mode 100644
index 0000000..d221473
--- /dev/null
+++ b/kernel-devel/kernel-build/Makefile
@@ -0,0 +1,9 @@
+all:
+	pdflatex pres_kernel-build_de.tex
+	pdflatex hints_kernel-build_de.tex
+	pdflatex handout_kernel-build_de.tex
+	pdflatex handout_kernel-build_de.tex
+
+clean:
+	rm -f *.aux *.log *.pdf *.log *.snm *.toc *.vrb *.nav *.out
+
diff --git a/kernel-devel/kernel-build/handout_kernel-build_de.tex b/kernel-devel/kernel-build/handout_kernel-build_de.tex
index 4c391b2..f0e5fae 100644
--- a/kernel-devel/kernel-build/handout_kernel-build_de.tex
+++ b/kernel-devel/kernel-build/handout_kernel-build_de.tex
@@ -1,17 +1,230 @@
-\documentclass{article}
+\documentclass{lxarticle}
 \usepackage{german}
 \usepackage[utf8]{inputenc}
+\usepackage{lxheaders}
+\usepackage{lxextras}
 
 \begin{document}
 
-\section*{Titel}
+\section*{Kernel konfigurieren und kompilieren}
 
-\subsection*{Abschnitt1}
+\subsection*{Vorarbeiten}
 
-Text
+Bevor man einen Kernel konfigurieren kann, sollte man wissen, was man will.
+Das hört sich zunächst nach einer trivialen Binsenweisheit an, kann aber
+manchmal tatsächlich nicht ganz einfach sein.
 
-\subsection*{Abschnitt2}
+Zunächst sollte man möglichst viele Informationen über die fragliche Hardware
+sammeln. Dazu gehört die genaue Prozessorversion sowie Typen und Versionen
+der angeschlossenen Chips. Insbesondere die Chips, die bereits beim Booten
+benötigt werden, sollten klar sein. Dazu gehören auf üblichen PCs der,
+Chipsatz mit ATA/SATA-Controller oder, je nach gewünschter Bootquelle auch
+der USB- oder Netzwerk-Chip.
+
+Bei Embedded Devices kommen oft noch NAND-Controller hinzu. In diesem Fall
+sollte man auch über die genauen Daten der angeschlossenen NAND-Chips
+informiert sein.
+
+Weiterhin muss man sich überlegen, von welchen Dateisystemen man booten
+möchte. Gängige Varianten sind ext2, ext3, NFS, oder NAND-Dateisysteme wie
+jffs2 oder ubifs. FAT eignet sich nicht für ein Linux-Rootfilesystem, da es
+beispielsweise keine Gerätedateien unterstützt. Will man Linux von einem
+USB-Stick booten, so wird man diesen dazu beispielsweise mit einem
+ext2-Dateisystem versehen.
+
+ \subsection*{Kernel-Konfiguration}
+
+Mit diesen Informationen versehen, kann man jetzt die Konfiguration beginnen.
+Dies erfolgt durch Eingabe von
+
+\cmd{make menuconfig}
+
+Abbildung \ref{img:menuconfig} zeigt die oberste Ebene des Menüs, das dann erscheint.
+
+
+\begin{figure}[h]
+\centering
+\includegraphics[width=0.8\textwidth]{images/menu_rt_001.png}
+\caption{Menü zur Kernel-Konfiguration}
+\label{img:menuconfig}
+\end{figure}
+
+Am oberen Rand gibt das Menü eine stichwortartige Erklärung zur Bedienung.
+Man sollte bei der Konfiguration zuerst grundlegende Dinge wie den
+Prozessortyp angeben, da untergeordnete Eigenschaften oder Treiber davon
+abhängig sein können.
+
+\subsection*{Module, ja oder nein?}
+Bei üblichen Kerneln für Desktop-Systeme wird man immer einen Großteil der
+Treiber als Module kompilieren. Solche Rechner besitzen viele Schnittstellen,
+über die man später die Hardware erweitern kann, und kann den Kernel bereits
+mit den möglicherweise vorkommenden Treiber-Modulen ausstatten. Diese werden
+dann nur bei Bedarf nachgeladen.
+
+Bei Embedded Systems ist die Situation anders. Hier ist die Hardware meist
+fest vorgegeben, so dass man schon beim Kompilieren genau weiss, welche Treiber
+benötigt werden. Ausserdem ist der im Rootfs zur Verfügung stehende Platz oft
+beschränkt, man wird hier ungern Speicher für unnötige Treiber-Module
+verschwenden.
+
+Andererseits ist es manchmal praktisch, einen Treiber als Modul vorliegen
+zu haben. Speziell während der Entwicklung eines eigenen Treibers ist es
+vorteilhaft, dass man einfach durch Austausch des Moduls eine neue Version
+ausprobieren kann. Unter Linux muss man dabei nicht einmal neu booten,
+sondern kann einen Treiber mit 
+
+\cmd{modprobe mein\_modul} installieren und mit
+
+\cmd{rmmod mein\_modul} wieder deinstallieren.
+
+Die Entscheidung, ob man einen Kernel ganz ohne Module baut, hängt vom
+Einzelfall ab. Bei Embedded Systems kommt dies aber durchaus öfter vor.
+
+Aus verständlichen Gründen dürfen Treiber, die zum Booten und Mounten des
+Rootfs benötigt werden, niemals als Module gebaut werden!
+
+\subsection*{initrd}
+
+Die Kernel von Distributionen haben das Problem, dass sie auf möglichst vielen
+unterschiedlichen Rechnern booten müssen. Würde man die Treiber für alle
+denkbaren Kombinationen fest in den Kernel einkompilieren, so hätte man einen
+riesigen Kernel, von dem der Großteil des Codes niemals benutzt würde.
+
+Die statt dessen verwendete Lösung besteht in einem Verfahren, bei dem der
+Kernel beim Booten eine RAM-Disk anlegt und diese mit einem vorbereiteten
+Image füllt. Das Image enthält sämtliche in Frage kommenden Treiber als Module.
+Nach dem Booten und dem Mounten des Root-Filesystems kann die RAM-Disk wieder
+aus dem Speicher entfernt werden. Dieses Verfahren nennt man \emph{initrd}
+(von \emph{Initial RAM Disk}).
+
+Wenn man einen Kernel für ein bestimmtes Board selbst kompiliert, braucht man
+nie eine initrd, da man ja genau die richtigen Treiber fest einkompilieren kann.
+
+\subsection*{initramfs}
+
+Ein anderes Verfahren, bei dem der Kernel zunächst eine RAM-Disk anlegt, ist
+\emph{initramfs}. Im Unterschied zu initrd wird diese aber nicht aus einem
+externen Image geladen, sondern das Image wird bereits beim Kompilieren zum
+Kernel dazugelinkt. Auch hier wird der von der RAM-Disk belegte Speicher am
+Ende wieder freigegeben.
+
+Das initramfs wird vom Kernel wie ein normales Root-Filesystem gemountet.
+Üblicherweise verwendet man ein minimales System, etwa basierend auf uclibc
+und einer busybox. Man kann in den Startskripten dieses Minimalsystems jetzt
+Aktionen ausführen, bevor das eigentliche Rootfs gemountet wird.
+
+Eine Anwendung dieses Verfahrens ist ein kleiner Bootkernel, der von einem
+IPL gestartet wird. In seinem initramfs befinden sich Startskripte, die den
+eigentlichen Produktiv-Kernel aus einer beliebigen Quelle nachladen und dann
+per \cmd{kexec} starten. Der Vorteil bei diesem Verfahren ist, dass der
+Bootkernel bereits jeden beliebigen Treiber (beispielsweise einen kompletten
+USB-Stack) enthalten kann, während Bootloader meist nur unvollständig mit
+den gängigsten Treibern versehen sind.
+
+Eine weitere Anwendung sind Firmware-Updates. So könnten die Startskripte
+des initramfs beispielsweise auf einem Server nachschauen, ob Updates
+vorhanden sind, und diese dann anwenden.
+
+\subsection*{Kernel kompilieren}
+
+Nach abgeschlossener Kernel-Konfiguration kompiliert man den Kernel einfach
+durch Eingabe von
+
+\begin{lstlisting}
+make
+\end{lstlisting}
+
+Falls der zum Kompilieren verwendete Rechner mehrere CPUs besitzt, kann man
+den Vorgang beschleunigen, indem man \cmd{make} anweist, mehrere Jobs
+gleichzeitig zu starten. Für die Zahl der Jobs ist eine häufig genannte
+Empfehlung die doppelte Anzahl der CPUs plus eins. Auf einem Dual-Core würde
+man also folgenden Befehl verwenden:
+
+\begin{lstlisting}
+make -j3
+\end{lstlisting}
+
+Will man den Kernel für eine andere Architektur als die des Compile-Rechners
+crosskompilieren, so muss man \cmd{make} mitteilen, mit welcher Toolchain und
+für welche Architektur gebaut werden soll. Damit man die doch etwas länglichen
+Optionen nicht immer wieder von Hand eintippen muss, schreibt man sie am Besten
+in ein kleines Skript, das man dann anstelle von \cmd{make} aufruft. Ein Skript
+für die ARM-Architektur unter Verwendung der Codesourcery-Toolchain 2007q3
+könnte etwa so aussehen:
+
+\begin{lstlisting}
+#!/bin/sh
+
+ARCH="arm"
+CROSS="/opt/arm-2007q3/bin/arm-none-linux-gnueabi-"
+export INSTALL_MOD_PATH="/rfs"
+
+make ARCH=$ARCH CROSS_COMPILE=$CROSS $@
+\end{lstlisting}
+
+Speichert man dies beispielsweise unter dem Namen \cmd{makearm} im
+Hauptverzeichnis der Kernelquellen, so ergibt sich folgender Aufruf:
+\begin{lstlisting}
+./makearm -j3
+\end{lstlisting}
+
+\subsection*{Kernel installieren}
+
+Einen Kernel für den lokalen Rechner (also den, auf dem man auch kompiliert
+hat) installiert man einfach durch Eingabe von
+
+\begin{lstlisting}
+make install
+\end{lstlisting}
+
+Dies führt folgende Aktionen durch (Beispiel für einen Kernel 2.6.30):
+\begin{itemize}
+\item Falls es im Verzeichnis \cmd{/boot} bereits ein \cmd{vmlinuz-2.6.30}
+	gibt, wird es in \cmd{vmlinuz-2.6.30.old} umbenannt
+\item Kopieren von \cmd{arch/<Architektur-Name>/boot/zImage} nach
+	\cmd{/boot/vmlinuz-2.6.30}
+\item Anlegen eines symbolischen Link \cmd{vmlinuz -> vmlinuz-2.6.30} in
+	\cmd{/boot}
+\end{itemize}
+
+Anschliessend darf man nicht vergessen, auch die Module des neuen Kernels
+zu installieren:
+
+\begin{lstlisting}
+make modules_install
+\end{lstlisting}
+
+Dabei werden alle Module (Dateien mit der Endung \cmd{*.ko} in Verzeichnisse
+unter \cmd{/lib/modules/2.6.30/...} kopiert. Ausserdem werden dort
+Zusatzinformationen zu den Modulen und ihren Abhängigkeiten generiert.
+
+\emph{VORSICHT!} Wenn man einen Kernel für eine andere Architektur
+crosskompiliert hat, darf man \emph{NIEMALS} leichtfertig
+\cmd{make modules\_install} aufrufen, da dies ohne weitere Warnung die
+eigenen Module mit den natürlich nicht verwendbaren Modulen der fremden
+Architektur überschreiben würde!
+
+Das oben aufgeführte Skript zeigt die korrekte Vorgehensweise. In der Variablen
+\cmd{INSTALL\_MOD\_PATH} kann man ein anderes Root-Filesystem angeben, in das
+die Module installiert werden sollen. Im Beispiel oben würde der Befehl
+
+\begin{lstlisting}
+./makearm modules_install
+\end{lstlisting}
+
+die Module nach \cmd{/rfs/lib/modules/2.6.30/...} installieren. Hat man sein
+Root-Filesystem per NFS aus diesem Verzeichnis gemountet, so stehen die Module
+sofort und ohne Reboot zur Verfügung. Diese Vorgehensweise hat sich bei der
+Entwicklung von Treibern für Embedded Systems sehr bewährt.
+
+\subsection*{Kontrollfragen}
+
+\begin{enumerate}
+\item Beschreiben Sie Unterschiede zwischen initrd und initramfs.
+\item Warum braucht man bei selbst kompilierten Kerneln in der Regel keine
+	initrd?
+\item Nennen Sie eine Anwendung von initramfs.
+\end{enumerate}
 
-Text
 
 \end{document}
diff --git a/kernel-devel/kernel-build/images/menu_rt_001.png b/kernel-devel/kernel-build/images/menu_rt_001.png
new file mode 100644
index 0000000..27f26cd
--- /dev/null
+++ b/kernel-devel/kernel-build/images/menu_rt_001.png
diff --git a/kernel-devel/kernel-build/pres_kernel-build_de.tex b/kernel-devel/kernel-build/pres_kernel-build_de.tex
index 07db328..1489f12 100644
--- a/kernel-devel/kernel-build/pres_kernel-build_de.tex
+++ b/kernel-devel/kernel-build/pres_kernel-build_de.tex
@@ -1,24 +1,23 @@
-\documentclass{article}
+\documentclass{beamer}
+\usetheme{linutronix}
 \usepackage{german}
 \usepackage[utf8]{inputenc}
+\usepackage{pgf}
+\usepackage{graphicx}
+\usepackage{lxextras}
 
-\begin{document}
-
-\section*{Block \lq Was ist Linux?\rq}
+\title{Linux-Kernel konfigurieren und kompilieren}
+\institute{Linutronix GmbH}
 
-\subsection*{Lernziele}
-\begin{itemize}
-\item Lernziel 1
-\item Lernziel 2
-\item Lernziel 3
-\end{itemize}
+\begin{document}
 
-\subsection*{Unterrichts-Ablauf}
+\maketitle
 
-Hinweise zur Präsentation, Zeitplanung, etc.
 
-\subsection*{Übungen bei vorhandener Hardware}
+% ----- Slide ------------------
+\begin{frame}
+\frametitle{Hallo}
+\end{frame}
 
-Hinweise zu Übungen, Zeitlimit dazu.
 
 \end{document}
diff --git a/kernel-devel/uio-driver/Makefile b/kernel-devel/uio-driver/Makefile
new file mode 100644
index 0000000..d212291
--- /dev/null
+++ b/kernel-devel/uio-driver/Makefile
@@ -0,0 +1,10 @@
+all:
+	pdflatex pres_uio-driver_de.tex
+	pdflatex pres_uio-driver_en.tex
+	pdflatex hints_uio-driver_de.tex
+	pdflatex handout_uio-driver_de.tex
+	pdflatex handout_uio-driver_de.tex
+
+clean:
+	rm -f *.aux *.log *.pdf *.log *.snm *.toc *.vrb *.nav *.out
+
diff --git a/kernel-devel/uio-driver/images/greg-all-hardware.jpg b/kernel-devel/uio-driver/images/greg-all-hardware.jpg
new file mode 100644
index 0000000..f7ab989
--- /dev/null
+++ b/kernel-devel/uio-driver/images/greg-all-hardware.jpg
diff --git a/kernel-devel/uio-driver/images/greg-kernel-org.jpg b/kernel-devel/uio-driver/images/greg-kernel-org.jpg
new file mode 100644
index 0000000..dbfb915
--- /dev/null
+++ b/kernel-devel/uio-driver/images/greg-kernel-org.jpg
diff --git a/kernel-devel/uio-driver/images/hjk-desperate.jpg b/kernel-devel/uio-driver/images/hjk-desperate.jpg
new file mode 100644
index 0000000..740f574
--- /dev/null
+++ b/kernel-devel/uio-driver/images/hjk-desperate.jpg
diff --git a/kernel-devel/uio-driver/images/ioctl-vs-uio.png b/kernel-devel/uio-driver/images/ioctl-vs-uio.png
new file mode 100644
index 0000000..8536934
--- /dev/null
+++ b/kernel-devel/uio-driver/images/ioctl-vs-uio.png
diff --git a/kernel-devel/uio-driver/images/konventioneller-treiber.png b/kernel-devel/uio-driver/images/konventioneller-treiber.png
new file mode 100644
index 0000000..bea54da
--- /dev/null
+++ b/kernel-devel/uio-driver/images/konventioneller-treiber.png
diff --git a/kernel-devel/uio-driver/images/uio-treiber.png b/kernel-devel/uio-driver/images/uio-treiber.png
new file mode 100644
index 0000000..caa2152
--- /dev/null
+++ b/kernel-devel/uio-driver/images/uio-treiber.png
diff --git a/kernel-devel/uio-driver/pres_uio-driver_en.tex b/kernel-devel/uio-driver/pres_uio-driver_en.tex
new file mode 100644
index 0000000..8468894
--- /dev/null
+++ b/kernel-devel/uio-driver/pres_uio-driver_en.tex
@@ -0,0 +1,302 @@
+\documentclass{beamer}
+\usetheme{linutronix}
+\usepackage{german}
+\usepackage[utf8]{inputenc}
+\usepackage{pgf}
+\usepackage{graphicx}
+
+\title{The Userspace I/O Framework (UIO)}
+\author{Hans-Jürgen Koch}
+\institute{Linutronix GmbH}
+
+\begin{document}
+
+\maketitle
+
+% ----- Slide "Desperate programmer" ------------------
+\begin{frame}
+\includegraphics[width=11cm]{images/hjk-desperate.jpg}
+\end{frame}
+
+% ----- Slide "Linux device drivers" ------------------
+\begin{frame}
+\frametitle{Linux device drivers}
+\pause
+\begin{itemize}
+\item Standard devices
+\pause
+\item Non-standard devices
+\end{itemize}
+\end{frame}
+
+% ----- Slide "Standard devices" -----------------------
+\begin{frame}
+\frametitle{Standard devices}
+\pause
+\begin{itemize}
+\item Handled by a kernel subsystem (USB, networking...)
+\pause
+\item Hardware specific part relatively small
+\pause
+\item Examples of similar drivers available
+\pause
+\item Can probably be included in mainline kernel 
+\pause
+\begin{block}{Standard devices should not be handled by UIO !}
+\end{block}
+\end{itemize}
+\end{frame}
+
+% ----- Slide "Problematic devices" -------------------
+\begin{frame}
+\frametitle{Problematic devices}
+\pause
+\begin{itemize}
+\item Doesn't fit into a standard kernel subsystem
+\pause
+\item Almost everything is hardware specific
+\pause
+\item Driver becomes large, no similar example drivers
+\pause
+\item Driver often invents its own ioctl based API
+\pause
+\item Will probably not be included in mainline kernel
+\pause
+\begin{block}{Drivers for such devices are often buggy and hard to maintain !}
+\end{block}
+\end{itemize}
+\end{frame}
+
+% ----- Slide "In-kernel driver" ------------------
+\begin{frame}
+\includegraphics[width=11cm]{images/konventioneller-treiber.png}
+\end{frame}
+
+% ----- Slide "UIO driver" ------------------
+\begin{frame}
+\includegraphics[width=11cm]{images/uio-treiber.png}
+\end{frame}
+
+% ----- Slide "How UIO works" --------------------------
+\begin{frame}
+\frametitle{How UIO works}
+\pause
+\begin{itemize}
+\item Device memory can be mapped to userspace
+\pause
+\item All data exchange is done through this memory
+\pause
+\item All device control is done through this memory
+\pause
+\item Interrupts are acknowledged in the kernel...
+\pause
+\item ...and then handled in userspace
+\pause
+\begin{block}{A small kernel module is still needed}
+\end{block}
+\end{itemize}
+\end{frame}
+
+% ----- Slide "Kernel: interrupt handler" --------------------------
+\begin{frame}[fragile]
+\frametitle{Kernel: interrupt handler}
+\begin{verbatim}
+irqreturn_t my_handler(int irq, struct uio_info *dev_info)
+{
+    if (IRQ is not caused by my hardware)
+        return IRQ_NONE;
+
+    /* Disable interrupt */
+    (Perform some register access to silence the IRQ line)
+
+    return IRQ_HANDLED;
+}
+\end{verbatim}
+\end{frame}
+
+% ----- Slide "Kernel: probe() function" --------------------------
+\begin{frame}[fragile]
+\frametitle{Kernel: probe() function}
+\begin{verbatim}
+int pci_probe(struct pci_dev *dev,
+              const struct pci_device_id *id)
+{
+    ...
+    allocate and fill struct uio_info
+    ...
+    call uio_register_device()    
+}
+\end{verbatim}
+\end{frame}
+
+% ----- Slide "Kernel: struct uio_info" --------------------------
+\begin{frame}[fragile]
+\frametitle{Kernel: struct uio\_info}
+\begin{verbatim}
+struct uio_info {
+    struct uio_device *uio_dev;
+    char *name;
+    char *version;
+    struct uio_mem mem[MAX_UIO_MAPS];
+    long irq;
+    unsigned long irq_flags;
+    void *priv;
+    irqreturn_t (*handler)(int irq, struct uio_info *dev_info);
+    int (*mmap)(struct uio_info *info, struct vm_area_struct *vma);
+    int (*open)(struct uio_info *info, struct inode *inode);
+    int (*release)(struct uio_info *info, struct inode *inode);
+};
+\end{verbatim}
+\end{frame}
+
+% ----- Slide "Kernel: struct uio_mem" --------------------------
+\begin{frame}[fragile]
+\frametitle{Kernel: struct uio\_mem}
+\begin{verbatim}
+struct uio_mem {
+    unsigned long addr;
+    unsigned long size;
+    int memtype;
+    void __iomem *internal_addr;
+    struct uio_map *map;
+};
+\end{verbatim}
+\end{frame}
+
+% ----- Slide "Userspace part of driver" --------------
+\begin{frame}
+\frametitle{Userspace: Overview}
+\pause
+\begin{itemize}
+\item Find device in sysfs (/sys/class/uio/...)
+\pause
+\item Get device information from sysfs
+\pause
+\item Open /dev/uioX
+\pause
+\item Use mmap() to get a pointer to the devices's memory
+\pause
+\item Initialize device, enable interrupt generation
+\pause
+\item Perform a blocking read() to wait for interrupts
+\end{itemize}
+\end{frame}
+
+% ----- Slide "Hello UIO world" --------------
+\begin{frame}[fragile]
+\frametitle{Hello UIO world}
+\pause
+\begin{verbatim}
+int32_t irq_cnt;
+int fd = open("/dev/uio0", O_RDWR);
+u16 *mem = mmap(..., n*getpagesize());
+mem[...] = ...
+while (read(fd, &irq_cnt, 4)) {
+    printf("irq count = %d\n", irq_cnt);
+}
+\end{verbatim}
+\end{frame}
+
+% ----- Slide "Performance considerations" --------------
+\begin{frame}
+\frametitle{Performance considerations}
+\pause
+\begin{itemize}
+\item Interrupt latency
+\pause
+\item Memory/register access
+\end{itemize}
+\end{frame}
+
+% ----- Slide "ioctl vs. UIO" ------------------
+\begin{frame}
+\includegraphics[width=10cm]{images/ioctl-vs-uio.png}
+\end{frame}
+
+% ----- Slide "Publish your driver!" --------------
+\begin{frame}
+\frametitle{Publish your driver!}
+\pause
+\begin{itemize}
+\item Get rid of maintenance work!
+\pause
+\item Send your patch to the UIO maintainers
+\pause
+\item Cc: linux-kernel@vger.kernel.org
+\pause
+\item Publish your userspace code, if possible
+\pause
+\item Make it LGPL, if possible
+\pause
+\item An open driver helps selling your hardware!
+\end{itemize}
+\end{frame}
+
+% ----- Slide "Greg: Support all hardware on earth" ---
+\begin{frame}
+\includegraphics[width=11cm]{images/greg-all-hardware.jpg}
+\end{frame}
+
+% ----- Slide "Greg: All drivers in kernel.org tree" --
+\begin{frame}
+\includegraphics[width=11cm]{images/greg-kernel-org.jpg}
+\end{frame}
+
+% ----- Slide "Legal issues" --------------------------
+\begin{frame}
+\frametitle{Legal issues}
+\pause
+\begin{itemize}
+\item Userspace code can be under any licence
+\pause
+\item Kernel module MUST be GPL
+\pause
+\item Avoid trickery and gray areas
+\end{itemize}
+\end{frame}
+
+% ----- Slide "Tools" --------------------------
+\begin{frame}
+\frametitle{Tools}
+\pause
+\begin{itemize}
+\item lsuio
+\pause
+\item TODO: libuio (nearly ready)
+\end{itemize}
+\end{frame}
+
+% ----- Slide "OSADL" --------------------------
+\begin{frame}
+\frametitle{OSADL}
+\pause
+\begin{itemize}
+\item Open Source Automation Development Lab
+\pause
+\item http://www.osadl.org
+\pause
+\item Hosts some UIO code
+\end{itemize}
+\end{frame}
+
+% ----- Slide "Future" --------------------------
+\begin{frame}
+\frametitle{Future}
+\pause
+\begin{itemize}
+\item DMA support
+\pause
+\item get UIO tools and libuio into Linux Distributions
+\end{itemize}
+\end{frame}
+
+% ----- Slide "Thanks for listening!" ----------
+\begin{frame}
+\frametitle{Thanks for listening!}
+\pause
+\begin{itemize}
+\item Questions ?
+\end{itemize}
+\end{frame}
+
+\end{document}