Aufräumen und neu strukturieren Teil 1

- alle images wurden ins Wurzelverzeichnis verschoben

- TEXINPUTS wird projektspezifisch gesetzt

- es besteht die Möglichkeit einzelne pdfs zu generieren (wie bisher)
   desweiteren ist es möglich eigene Zusammenstellungen anzulegen

- Einsstellungen welche das Design der Dokumente definieren werden nun
   in config*.tex & tail*.tex im Wurzelverzeichnis definiert

- templates an neue Umgebung angepasst

- in jedem Kapitelverzeichnis liegt nun eine Datei section welche das Kapitel
   beschreibt (mind. überschrift). Diese kann ggf. inkludiert werden.

- TODO: es sind noch nicht alle Dokumente auf die neue Struktur umgestellt
   (siehe Makefile)

Signed-off-by: Manuel Traut <manut@linutronix.de>

1 files changed, 9 insertions, 15 deletions

diff --git a/flash-memory/mtd/handout_mtd_de.tex b/flash-memory/mtd/handout_mtd_de.tex
index b11c3a5..15c642f 100644
--- a/flash-memory/mtd/handout_mtd_de.tex
+++ b/flash-memory/mtd/handout_mtd_de.tex
@@ -1,14 +1,8 @@
-\documentclass{lxarticle}
-\usepackage{german}
-\usepackage[utf8]{inputenc}
-\usepackage{lxheaders}
-\usepackage{lxextras}
+\input{confighandout}
 
-\begin{document}
+\subsection{Memory Technology Devices (MTD)}
 
-\section*{Memory Technology Devices (MTD)}
-
-\section*{Was sind Memory Technology Devices?}
+\subsubsection{Was sind Memory Technology Devices?}
 
 Prinzipiell kann jedes Stück Speicher als MTD dargestellt werden,
 es gibt sogar Treiber, die einfach einen RAM-Bereich exportieren.
@@ -30,7 +24,7 @@ des Geräts von einem eingebauten Controller verwaltet und erscheint für
 den Kernel als normales Block-Device (wie eine Festplatte). NAND-typische
 Eigenschaften wie die Größe eines Eraseblocks bleiben dem Kernel unbekannt.
 
-\section*{Das MTD-Subsystem im Kernel}
+\subsubsection{Das MTD-Subsystem im Kernel}
 
 Wie im Linux-Kernel üblich, werden die Treiber gleichartiger Geräte von
 einem eigenen Subsystem verwaltet. Diese Vorgehensweise ermöglicht eine
@@ -40,7 +34,7 @@ von Treibern, da ihre Struktur vorgegeben ist, und sie sich nicht mehr
 um immer wiederkehrenden generischen Code oder das Interface zum
 Userspace kümmern müssen.
 
-\subsection*{Was das MTD-Subsystem im Kernel macht...}
+\paragraph{Was das MTD-Subsystem im Kernel macht...}
 
 Das MTD-Subsystem verwaltet zunächst die physikalische Struktur eines
 Chips, kennt also z.B. dessen Zusammensetzung aus einer gewissen Anzahl
@@ -58,7 +52,7 @@ Anhand dieser Device-Dateien kann jetzt auf die einzelnen Partitionen
 zugegriffen werden. Dabei können Datenblöcke gelesen und geschrieben
 werden, ausserdem können Eraseblöcke gelöscht werden.
 
-\subsection*{...und was das MTD-Subsystem \emph{nicht} macht...}
+\paragraph{...und was das MTD-Subsystem \emph{nicht} macht...}
 
 Das MTD-Subsystem wurde bewusst als sehr dünner Abstraktions-Layer
 angelegt. Es geht lediglich um die einheitliche Schnittstelle und
@@ -73,7 +67,7 @@ Ausser der NAND-eigenen ECC-Fehlerkorrektur gibt es keine weiteren
 Schutzmechanismen, falls beim Schreiben der Strom ausfällt, gehen
 Daten verloren.
 
-\subsection*{Erweiterungen}
+\paragraph{Erweiterungen}
 
 Aus historischen Gründen verfügt der Kernel noch über den \cmd{mtdblock}-
 Treiber. Dieser emuliert für ein mtd-Device \cmd{/dev/mtd0} ein
@@ -93,7 +87,7 @@ Interesse als veraltet und schlecht gewartet.
 Durch die Einführung von UBI und ubifs sind derartige MTD-Erweiterungen
 für die meisten Anwendungen schlicht überflüssig geworden.
 
-\section*{MTD-Tools}
+\subsubsection{MTD-Tools}
 
 Um auf mtd-Devices zugreifen zu können, haben die MTD-Entwickler eine Reihe
 von Tools entwickelt, die von den meisten Distributionen als Paket bereit
@@ -135,4 +129,4 @@ Datei \cmd{data.txt} gespeichert.
 \emph{Hinweis:} Alle diese Tools kennen die Option \cmd{--help}, die alle
 verfügbaren Optionen auflistet und kurz erläutert.
 
-\end{document}
+\input{tailhandout}