From 22b4e0ea46fc6f8f04e045ac5469d045dff43e9e Mon Sep 17 00:00:00 2001 From: "Hans J. Koch" Date: Fri, 19 Jun 2009 01:34:07 +0200 Subject: Completed linux-basics/boot-process/handout_boot-process_de.tex --- .../boot-process/handout_boot-process_de.tex | 150 ++++++++++++++++++++- 1 file changed, 144 insertions(+), 6 deletions(-) diff --git a/linux-basics/boot-process/handout_boot-process_de.tex b/linux-basics/boot-process/handout_boot-process_de.tex index 4c391b2..7f39dc7 100644 --- a/linux-basics/boot-process/handout_boot-process_de.tex +++ b/linux-basics/boot-process/handout_boot-process_de.tex @@ -1,17 +1,155 @@ -\documentclass{article} +\documentclass{lxarticle} \usepackage{german} \usepackage[utf8]{inputenc} +\usepackage{lxheaders} +\usepackage{lxextras} \begin{document} -\section*{Titel} +\section*{Der Linux-Boot-Prozess} -\subsection*{Abschnitt1} +\subsection*{Aufgaben des Bootloaders} -Text +Hauptaufgabe des Bootloaders ist die rudimentäre Initialisierung der +Hardware, so dass mindestens das RAM benutzt werden kann. Dazu ist auf den +meisten Boards die Initialisierung eines (S)DRAM-Controllers erforderlich. -\subsection*{Abschnitt2} +Soll das Board aus einem NAND-Flash booten können, so muss auch dessen +Controller initialisiert werden. -Text +Viele Prozessoren beinhalten PLLs, die aus dem Prozessortakt andere Clocks +für verschiedene Peripherie-Einheiten generieren. Auch diese müssen +initialisiert werden. + +Anschließend müssen die Peripherie-Einheiten initialisiert werden, die +der Bootloader benötigt, um den Kernel laden zu können. Für TFTP-Boot wäre +dies beispielsweise der Netzwerk-Chip. + +Meist ist es auch erwünscht, dass der Bootloader eine serielle Schnittstelle +initialisiert. Dies ermöglicht nicht nur hilfreiche Meldungen aus dem +Bootloader, es ermöglicht auch dem Kernel bereits im frühen Stadium des +Bootvorgangs die Ausgabe von Meldungen (und nicht erst nach dem Laden seines +UART-Treibers und der Konsole). Viele Bootloader bieten ausserdem eine Art +Monitorprogramm, mit dem man mit Hilfe eines Terminalprogramms interaktiv +Einstellungen ändern oder Speicher lesen und schreiben kann. + +Nach erfolgreicher Initialisierung lädt der Bootloader von der gewählten +Quelle das komprimierte Kernel-Image ins RAM. Am Anfang eines komprimierten +zImage steht (natürlich unkomprimiert) der Dekompressor-Code. Der Bootloader +springt diese Adresse an und hat damit seine Arbeit beendet. Alles weitere +läuft im Kernel ab. + +\subsection*{Gängige Bootloader} + +Die Wahl des Bootloaders ist weitgehend eine Geschmacksfrage. Die +verbreiteten Bootloader U-Boot und Redboot bieten im Wesentlichen die gleiche +Funktionalität. Die Bedienung unterscheidet sich zwar deutlich, aber der +ohnehin nötige Einarbeitungsaufwand dürfte bei beiden etwa gleich sein. + +Auch beim Kompilieren dieser Bootloader sind die Unterschiede nicht gross. +Beide zeichnen sich durch schwer durchschaubaren Sourcecode und ein +eigenwilliges Buildsystem aus. + +Es gibt aber auch die Möglichkeit, ganz auf einen derartigen Bootloader zu +verzichten. Statt dessen verwendet man einen minimalen \emph{Initial Program +Loader (IPL)}, der lediglich die rudimentären Initialisierungsaufgaben +erfüllt und danach einen minimalen Bootkernel lädt und ausführt. Dieser +lädt wiederum den eigentlichen Produktiv-Kernel nach. + +Vorteile der letztgenannten Vorgehensweise sind hohe Flexibilität und die +Tatsache, dass man im Bootkernel schon nach wenigen hundert Millisekunden +jeden gewünschten Treiber zur Verfügung hat. Dadurch können in elegante +Weise Anforderungen wie das Anzeigen eines Bildes auf einem TFT (500 +Millisekunden nach dem Einschalten) gelöst werden. Wollte man dies mit +einem der oben erwähnten Bootloader erreichen, müsste man zunächst die +für das TFT benötigten Treiber vom Kernel in den Bootloader portieren und +dort zum Laufen bringen. Ähnliches gilt für andere gängige Forderungen, +wie das Booten von einem USB-Stick. + +Es erscheint als überflüssige Mühe, einen im Kernel bereits +funktionierenden Treiber in den Bootloader portieren zu müssen. Mit IPL und +Bootkernel sind ausserdem komplexe Aufgaben während des Bootvorgangs, +beispielsweise automatisierte und sichere Firmware-Updates leicht +realisierbar. + +\subsection*{Bootprobleme: Im Bootloader} + +Während der Entwicklungsphase sind Probleme im Bootloader besonders +unangenehm. Falls dieser bereits abstürzt, ehe er die serielle Schnittstelle +initialisieren konnte, so sieht man schlichtweg gar nichts. Aber auch bei +späteren Fehlern ist der Entwicklungszyklus mühsam, da man den Bootloader +meist erst mit einem JTAG-Adapter oder ähnlichen Werkzeugen ins Flash des +Boards befördern muss, bevor man den nächsten Versuch machen kann. Bei +Änderungen am Bootloader-Code ist daher große Sorgfalt geboten. Wenn möglich, +sollte man zu zweit an solchem Code arbeiten und sich ständig gegenseitig +kontrollieren. + +Häufige Problemquellen im Bootloader sind beispielsweise: + +\begin{itemize} +\item Der Bootloader wurde nicht korrekt ins Flash geschrieben. In einem Fall + passierte dies beispielsweise, wenn der Compiler ein Binary mit + ungerader Länge erzeugte. Aber auch falsche Konfiguration des JTAGer + kann zu solchen Problemen führen. +\item Im Bootloader wurden die Timings für Bus-Schnittstellen wie RAM oder + Flash nicht korrekt eingestellt. Gerade wenn die Timings nicht ganz + falsch, sondern nur grenzwertig sind, kann es zu schwer + reproduzierbaren Bootproblemen kommen. +\item Die Ladeadresse für den Kernel ist nicht korrekt. Bei manchen + Bootloadern kann es leicht zu Verwechslungen zwischen physikalischen + und virtuellen Adressen kommen. Weder U-Boot noch Redboot melden + einen Fehler, wenn man den Kernel an eine Adresse lädt, an der + sich überhaupt kein RAM befindet... +\item Beim Laden des Kernels per TFTP kann es zusätzlich weitere Probleme + geben, die mit dem Netzwerk zusammenhängen. Diese reichen von falsch + aufgesetzten TFTP-Servern über falsch konfigurierte DHCP-Server oder + falschen IP-Adressen bis hin zu Treiber- oder Hardware-Problemen. +\end{itemize} + +\subsection*{Bootprobleme: Im Kernel} + +Bootprobleme im Kernel sind vergleichsweise einfach zu finden, sobald man +eine Konsole auf der seriellen Schnittstelle hat. Der Kernel gibt meist recht +aussagekräftige Fehlermeldungen und bietet viele zusätzliche Debug-Funktionen, +die man in der Kernel-Konfiguration aktivieren kann. Falls sich der Kernel +bereits früher aufhängt, so dass man nach der Meldung + +\cmd{Uncompressing Linux.....} + +überhaupt nichts mehr sieht, dann wird es schwieriger. Man sollte zunächst +überprüfen, ob die im Bootloader vorgegebene Commandline für den Kernel +korrekt ist, insbesondere die Einstellung der für die Konsole verwendeten +seriellen Schnittstelle (\cmd{console=tty...}). + +Ein weiteres gängiges Problem ist, dass der Kernel am Ende des Bootvorgangs +kein Root-Filesystem mounten kann. Dies kann daran liegen, dass man bei der +Kernelkonfiguration vergessen hat, dass \emph{alle} für das Rootfs nötigen +Hardware- und Dateisystem-Treiber in den Kernel einkompiliert sein müssen +und nicht etwa als Module gebaut wurden. Bei Medien, die erst detektiert +werden müssen (z.B. SD-Karten) kann es passieren, dass das Medium noch nicht +bereit ist, wenn der Kernel es mounten will. In diesem Fall hilft der +Parameter \cmd{rootwait}. + +Falls der Kernel zwar das Rootfs mounten kann, aber danach mit einer +Fehlermeldung hängen bleibt, anstatt \cmd{/sbin/init} zu starten, dann +liegt dies oft an fehlenden Device-Nodes im Verzeichnis \cmd{/dev}. +Überprüfen Sie dies. + +\subsection*{Bootprobleme: In den Startskripten} + +Wenn der Kernel erfolgreich das Rootfs mounten und \cmd{/sbin/init} starten +konnte, wird letzteres versuchen, die in \cmd{/etc/inittab} angegebenen +Anweisungen auszuführen. Dies ist normalerweise zunächst der Aufruf eines +Startskripts, das in der Regel weitere Skripte und Programme aufruft. Je +nach Art der aufgerufenen Programme kann es hier zu weiteren Problemen +kommen. Dazu gehören etwa fehlerhafte Konfigurationsdateien, fehlende +Device-Nodes oder Ähnliches. + +Ausserdem kommt es bei Startskripten vor, dass diese nicht auf jede Situation +sauber und fehlertolerant reagieren. Man sollte vermeiden, dass sich das +Skript zur Konfiguration des Netzwerks aufhängt, wenn kein DHCP-Server +gefunden wurde oder kein Netzwerkkabel eingesteckt ist. Des weiteren sollte +das Skript selber erkennen, wenn über die Netzwerkschnittstelle das Rootfs +per NFS gemountet wurde, und dann eine Neukonfiguration tunlichst unterlassen. \end{document} -- cgit v1.2.3 From 03cf86041d8ec9aaebdfb3d787a37b725854d256 Mon Sep 17 00:00:00 2001 From: Jan Altenberg Date: Fri, 19 Jun 2009 04:14:47 +0200 Subject: Added lots of content for the RT basics stuff. --- realtime/rt-basics/images/ipipe.png | Bin 0 -> 18012 bytes realtime/rt-basics/images/ipipe.svg | 185 +++++++++++++++++++++ realtime/rt-basics/images/nuclear.png | Bin 0 -> 1134159 bytes realtime/rt-basics/images/preempt_rt.png | Bin 0 -> 26716 bytes realtime/rt-basics/images/preempt_rt.svg | 254 ++++++++++++++++++++++++++++ realtime/rt-basics/images/prio_inv.png | Bin 0 -> 23132 bytes realtime/rt-basics/images/prio_inv.svg | 204 +++++++++++++++++++++++ realtime/rt-basics/images/rtai.dia | Bin 0 -> 634 bytes realtime/rt-basics/images/rtai.dia~ | Bin 0 -> 801 bytes realtime/rt-basics/images/rtai.png | Bin 0 -> 33749 bytes realtime/rt-basics/images/rtai.svg | 273 ++++++++++++++++++++++++++++++ realtime/rt-basics/images/xenomai.png | Bin 0 -> 34356 bytes realtime/rt-basics/images/xenomai.svg | 274 +++++++++++++++++++++++++++++++ 13 files changed, 1190 insertions(+) create mode 100644 realtime/rt-basics/images/ipipe.png create mode 100644 realtime/rt-basics/images/ipipe.svg create mode 100644 realtime/rt-basics/images/nuclear.png create mode 100644 realtime/rt-basics/images/preempt_rt.png create mode 100644 realtime/rt-basics/images/preempt_rt.svg create mode 100644 realtime/rt-basics/images/prio_inv.png create mode 100644 realtime/rt-basics/images/prio_inv.svg create mode 100644 realtime/rt-basics/images/rtai.dia create mode 100644 realtime/rt-basics/images/rtai.dia~ create mode 100644 realtime/rt-basics/images/rtai.png create mode 100644 realtime/rt-basics/images/rtai.svg create mode 100644 realtime/rt-basics/images/xenomai.png create mode 100644 realtime/rt-basics/images/xenomai.svg diff --git a/realtime/rt-basics/images/ipipe.png b/realtime/rt-basics/images/ipipe.png new file mode 100644 index 0000000..b7468fa Binary files /dev/null and b/realtime/rt-basics/images/ipipe.png differ diff --git a/realtime/rt-basics/images/ipipe.svg b/realtime/rt-basics/images/ipipe.svg new file mode 100644 index 0000000..cc7baa9 --- /dev/null +++ b/realtime/rt-basics/images/ipipe.svg @@ -0,0 +1,185 @@ + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Xenomai Domain + + Linux Domain + + Interrupts + + + ..... + + + + ..... + + + + diff --git a/realtime/rt-basics/images/nuclear.png b/realtime/rt-basics/images/nuclear.png new file mode 100644 index 0000000..a434e91 Binary files /dev/null and b/realtime/rt-basics/images/nuclear.png differ diff --git a/realtime/rt-basics/images/preempt_rt.png b/realtime/rt-basics/images/preempt_rt.png new file mode 100644 index 0000000..463673f Binary files /dev/null and b/realtime/rt-basics/images/preempt_rt.png differ diff --git a/realtime/rt-basics/images/preempt_rt.svg b/realtime/rt-basics/images/preempt_rt.svg new file mode 100644 index 0000000..b186ef5 --- /dev/null +++ b/realtime/rt-basics/images/preempt_rt.svg @@ -0,0 +1,254 @@ + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Hardware + + Linux + + IRQThread + + App + + RT App + + IRQThread + ..... + Kernel + User + + + diff --git a/realtime/rt-basics/images/prio_inv.png b/realtime/rt-basics/images/prio_inv.png new file mode 100644 index 0000000..574afb3 Binary files /dev/null and b/realtime/rt-basics/images/prio_inv.png differ diff --git a/realtime/rt-basics/images/prio_inv.svg b/realtime/rt-basics/images/prio_inv.svg new file mode 100644 index 0000000..c20b77f --- /dev/null +++ b/realtime/rt-basics/images/prio_inv.svg @@ -0,0 +1,204 @@ + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Prio + Task 1 + Task 2 + Task 3 + + + + + blockiert + unterbrochen + Task 3 + Task 2 + + diff --git a/realtime/rt-basics/images/rtai.dia b/realtime/rt-basics/images/rtai.dia new file mode 100644 index 0000000..dedf883 Binary files /dev/null and b/realtime/rt-basics/images/rtai.dia differ diff --git a/realtime/rt-basics/images/rtai.dia~ b/realtime/rt-basics/images/rtai.dia~ new file mode 100644 index 0000000..c4024ff Binary files /dev/null and b/realtime/rt-basics/images/rtai.dia~ differ diff --git a/realtime/rt-basics/images/rtai.png b/realtime/rt-basics/images/rtai.png new file mode 100644 index 0000000..c6c21ce Binary files /dev/null and b/realtime/rt-basics/images/rtai.png differ diff --git a/realtime/rt-basics/images/rtai.svg b/realtime/rt-basics/images/rtai.svg new file mode 100644 index 0000000..39b34e4 --- /dev/null +++ b/realtime/rt-basics/images/rtai.svg @@ -0,0 +1,273 @@ + + + + + + + + + + + image/svg+xml + + + + + + + + + + Hardware + + RT Kernel + + Linux + + RT App + + RT App + + Linux App + + Linux App + + + + + + + FIFO + + + Userspace + Kernelspace + + + diff --git a/realtime/rt-basics/images/xenomai.png b/realtime/rt-basics/images/xenomai.png new file mode 100644 index 0000000..d1ff146 Binary files /dev/null and b/realtime/rt-basics/images/xenomai.png differ diff --git a/realtime/rt-basics/images/xenomai.svg b/realtime/rt-basics/images/xenomai.svg new file mode 100644 index 0000000..8f71daa --- /dev/null +++ b/realtime/rt-basics/images/xenomai.svg @@ -0,0 +1,274 @@ + + + + + + + + + + + image/svg+xml + + + + + + + + + + Hardware + + Adeos / IPIPE + + Linux + + Nucleus + + RT App + + Linux App + + + + + Userspace + Kernelspace + + RT App + + Skins + + + + + -- cgit v1.2.3 From 70f1e16d1f2994ef3c055fa914495f49f1b47700 Mon Sep 17 00:00:00 2001 From: Jan Altenberg Date: Fri, 19 Jun 2009 20:16:42 +0200 Subject: Completed RT Basics chapter --- realtime/rt-basics/images/dual_kernel.png | Bin 0 -> 43070 bytes realtime/rt-basics/images/dual_kernel.svg | 251 ++++++++++++++++++++++++++++ realtime/rt-basics/images/gpos_vs_rt.png | Bin 0 -> 124609 bytes realtime/rt-basics/images/gpos_vs_rt.svg | 134 +++++++++++++++ realtime/rt-basics/images/mar01.png | Bin 0 -> 43535 bytes realtime/rt-basics/images/mar01.svg | 122 ++++++++++++++ realtime/rt-basics/images/mar02.png | Bin 0 -> 72568 bytes realtime/rt-basics/images/mar02.svg | 158 +++++++++++++++++ realtime/rt-basics/images/mar03.png | Bin 0 -> 74787 bytes realtime/rt-basics/images/mar03.svg | 163 ++++++++++++++++++ realtime/rt-basics/images/preempt_rt.svg | 2 +- realtime/rt-basics/images/prio_inv.svg | 5 +- realtime/rt-basics/images/single_kernel.png | Bin 0 -> 34007 bytes realtime/rt-basics/images/single_kernel.svg | 234 ++++++++++++++++++++++++++ 14 files changed, 1067 insertions(+), 2 deletions(-) create mode 100644 realtime/rt-basics/images/dual_kernel.png create mode 100644 realtime/rt-basics/images/dual_kernel.svg create mode 100644 realtime/rt-basics/images/gpos_vs_rt.png create mode 100644 realtime/rt-basics/images/gpos_vs_rt.svg create mode 100644 realtime/rt-basics/images/mar01.png create mode 100644 realtime/rt-basics/images/mar01.svg create mode 100644 realtime/rt-basics/images/mar02.png create mode 100644 realtime/rt-basics/images/mar02.svg create mode 100644 realtime/rt-basics/images/mar03.png create mode 100644 realtime/rt-basics/images/mar03.svg create mode 100644 realtime/rt-basics/images/single_kernel.png create mode 100644 realtime/rt-basics/images/single_kernel.svg diff --git a/realtime/rt-basics/images/dual_kernel.png b/realtime/rt-basics/images/dual_kernel.png new file mode 100644 index 0000000..c58d156 Binary files /dev/null and b/realtime/rt-basics/images/dual_kernel.png differ diff --git a/realtime/rt-basics/images/dual_kernel.svg b/realtime/rt-basics/images/dual_kernel.svg new file mode 100644 index 0000000..31f80ec --- /dev/null +++ b/realtime/rt-basics/images/dual_kernel.svg @@ -0,0 +1,251 @@ + + + + + + + + + + + + + + image/svg+xml + + + + + + + Hardware + + + Micro Kernel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/realtime/rt-basics/images/gpos_vs_rt.png b/realtime/rt-basics/images/gpos_vs_rt.png new file mode 100644 index 0000000..07a4a79 Binary files /dev/null and b/realtime/rt-basics/images/gpos_vs_rt.png differ diff --git a/realtime/rt-basics/images/gpos_vs_rt.svg b/realtime/rt-basics/images/gpos_vs_rt.svg new file mode 100644 index 0000000..7862037 --- /dev/null +++ b/realtime/rt-basics/images/gpos_vs_rt.svg @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + image/svg+xml + + + + + + + RealtimeOperating System + General PurposeOperating System + + + + diff --git a/realtime/rt-basics/images/mar01.png b/realtime/rt-basics/images/mar01.png new file mode 100644 index 0000000..7f18317 Binary files /dev/null and b/realtime/rt-basics/images/mar01.png differ diff --git a/realtime/rt-basics/images/mar01.svg b/realtime/rt-basics/images/mar01.svg new file mode 100644 index 0000000..78d99db --- /dev/null +++ b/realtime/rt-basics/images/mar01.svg @@ -0,0 +1,122 @@ + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + diff --git a/realtime/rt-basics/images/mar02.png b/realtime/rt-basics/images/mar02.png new file mode 100644 index 0000000..f1f53a1 Binary files /dev/null and b/realtime/rt-basics/images/mar02.png differ diff --git a/realtime/rt-basics/images/mar02.svg b/realtime/rt-basics/images/mar02.svg new file mode 100644 index 0000000..3c9ac3a --- /dev/null +++ b/realtime/rt-basics/images/mar02.svg @@ -0,0 +1,158 @@ + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + RTAI / Fusion + + diff --git a/realtime/rt-basics/images/mar03.png b/realtime/rt-basics/images/mar03.png new file mode 100644 index 0000000..97ab7ba Binary files /dev/null and b/realtime/rt-basics/images/mar03.png differ diff --git a/realtime/rt-basics/images/mar03.svg b/realtime/rt-basics/images/mar03.svg new file mode 100644 index 0000000..25c40ad --- /dev/null +++ b/realtime/rt-basics/images/mar03.svg @@ -0,0 +1,163 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + diff --git a/realtime/rt-basics/images/preempt_rt.svg b/realtime/rt-basics/images/preempt_rt.svg index b186ef5..a9c0ac7 100644 --- a/realtime/rt-basics/images/preempt_rt.svg +++ b/realtime/rt-basics/images/preempt_rt.svg @@ -15,7 +15,7 @@ inkscape:version="0.46" sodipodi:docname="preempt_rt.svg" inkscape:output_extension="org.inkscape.output.svg.inkscape" - inkscape:export-filename="/home/jan/work/omnicron/schulung/realtime/rt-basics/images/ipipe.png" + inkscape:export-filename="/home/jan/work/omnicron/schulung/realtime/rt-basics/images/preempt_rt.png" inkscape:export-xdpi="90" inkscape:export-ydpi="90"> + inkscape:output_extension="org.inkscape.output.svg.inkscape" + inkscape:export-filename="/home/jan/work/omnicron/schulung/realtime/rt-basics/images/prio_inv.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90"> + + + + + + + + + + + + + image/svg+xml + + + + + + + Hardware + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- cgit v1.2.3 From 658ebb0590425e4d5a245292b30df4a58a7dbacb Mon Sep 17 00:00:00 2001 From: "Hans J. Koch" Date: Fri, 19 Jun 2009 21:21:02 +0200 Subject: Added linux-basics/sh-programming --- linux-basics/sh-programming/Makefile | 9 + .../sh-programming/handout_sh-programming_de.tex | 17 +- .../sh-programming/pres_sh-programming_de.tex | 247 ++++++++++++++++++++- 3 files changed, 259 insertions(+), 14 deletions(-) create mode 100644 linux-basics/sh-programming/Makefile diff --git a/linux-basics/sh-programming/Makefile b/linux-basics/sh-programming/Makefile new file mode 100644 index 0000000..325aad0 --- /dev/null +++ b/linux-basics/sh-programming/Makefile @@ -0,0 +1,9 @@ +all: + pdflatex pres_sh-programming_de.tex + pdflatex hints_sh-programming_de.tex + pdflatex handout_sh-programming_de.tex + pdflatex handout_sh-programming_de.tex + +clean: + rm -f *.aux *.log *.pdf *.log *.snm *.toc *.vrb *.nav *.out + diff --git a/linux-basics/sh-programming/handout_sh-programming_de.tex b/linux-basics/sh-programming/handout_sh-programming_de.tex index 4c391b2..5590e6e 100644 --- a/linux-basics/sh-programming/handout_sh-programming_de.tex +++ b/linux-basics/sh-programming/handout_sh-programming_de.tex @@ -1,17 +1,26 @@ -\documentclass{article} +\documentclass{lxarticle} \usepackage{german} \usepackage[utf8]{inputenc} +\usepackage{lxheaders} +\usepackage{lxextras} \begin{document} -\section*{Titel} +\section*{Einführung in die Shell-Programmierung} -\subsection*{Abschnitt1} +\subsection*{Aufbau von Shell-Skripten} Text -\subsection*{Abschnitt2} +\subsection*{Variablen und Parameter} Text +\subsection*{Bedingte Verzweigungen} + + +\subsection*{Schleifen} +\subsection*{Einbinden anderer Skripte} +\subsection*{Zugriff auf Dateien} + \end{document} diff --git a/linux-basics/sh-programming/pres_sh-programming_de.tex b/linux-basics/sh-programming/pres_sh-programming_de.tex index 07db328..dbecb3d 100644 --- a/linux-basics/sh-programming/pres_sh-programming_de.tex +++ b/linux-basics/sh-programming/pres_sh-programming_de.tex @@ -1,24 +1,251 @@ -\documentclass{article} +\documentclass{beamer} +\usetheme{linutronix} \usepackage{german} \usepackage[utf8]{inputenc} +\usepackage{pgf} +\usepackage{graphicx} +\usepackage{lxextras} + +\title{Einführung in die Shell-Programmierung} +\institute{Linutronix GmbH} \begin{document} -\section*{Block \lq Was ist Linux?\rq} +\maketitle -\subsection*{Lernziele} +% ----- Slide ------------------ +\begin{frame} +\frametitle{Aufbau von Shell-Skripten} \begin{itemize} -\item Lernziel 1 -\item Lernziel 2 -\item Lernziel 3 +\item Syntax: \cmd{\#!/ein/interpreter} +\pause +\item Beliebiges Programm als Interpreter möglich +\pause +\item Beispiele hier: \cmd{\#!/bin/sh} +\pause +\item Danach beliebige Shell-Befehle möglich \end{itemize} +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Hello World als Shell-Script} +\begin{lstlisting} +#!/bin/sh +echo Hello World +\end{lstlisting} +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Variablen und Parameter} +\begin{lstlisting} +#!/bin/sh + +MY_VAR=17 +PAR_1=$1 +datum=`date` + +echo variable is $(MYVAR), parameter is $(PAR_1) +\end{lstlisting} + +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Ausgabe-Umleitung} +\begin{lstlisting} +#!/bin/sh + +# How many lines in addr.txt contain "Jones" ? +# Store the result in "jones_count" +grep Jones addr.txt | wc -l > jones_count + +# Append a message to a log file +echo "My message" >> log_file + +exit 0 + +\end{lstlisting} + +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Bedingte Verzweigungen} +\begin{lstlisting} +#!/bin/sh + +if [ bedingung ] + then + ... + else + ... +fi + +# in one line: + +if [ bedingung ] ; then ... ; fi + +\end{lstlisting} + +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Bedingte Verzweigungen} +\begin{lstlisting} +#!/bin/sh + +# Zahlentests: -eq -ne -lt -gt -le -ge +zahl=15 +if [ $zahl -lt 20 ] ; then ... + +# String-Tests: = != < > -n -z +string="Hallo" +if [ $string != "hello" ] ; then ... + +\end{lstlisting} + +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Bedingte Verzweigungen} +\begin{lstlisting} +#!/bin/sh +# Dateitests, z.B. if [ -f $datei ] ; then ... +# Auswahl: +# -f ist eine normale Datei +# -d ist ein Verzeichnis +# -e existiert +# -s existiert und ist nicht leer +# -r ist lesbar +# -w ist schreibbar +# -x ist ausfuehrbar +# -b ist ein Block Device +# -c ist ein Character Device +\end{lstlisting} + +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Bedingte Verzweigungen} +\begin{lstlisting} +#!/bin/sh + +# Does addr.txt contain "Jones" ? +if grep Jones addr.txt ; then ... + +# Return value 0 means OK +exit 0 + +\end{lstlisting} +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Bedingte Verzweigungen} +\begin{lstlisting} +#!/bin/sh + +# Short circuit tests: + +make && make install + +grep Jones addr.txt || echo "No Jones found!" + +\end{lstlisting} +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Schleifen} +\begin{lstlisting} +#!/bin/sh + +for datei in datei1 datei2 datei3 +do + cp $datei $datei.bak +done + +for datei in * +do + ... +done + +\end{lstlisting} +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Schleifen} +\begin{lstlisting} +#!/bin/sh + +while [ bedingung ] +do + ... +done + +while [ bedingung ] ; do ... ; done + +# bedingung wie bei if + +\end{lstlisting} +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Funktionen} +\begin{lstlisting} +#!/bin/sh + +error_log() { + echo "Fehler: $1" >> my_log_file +} + +... + +error_log "Datei nicht gefunden." + +\end{lstlisting} +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Einbinden anderer Skripte} +\begin{lstlisting} +#!/bin/sh + +# Include an external script: +. my_other_script + +# run another script/command in the background: +my_other_script& + +\end{lstlisting} +\end{frame} + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Zugriff auf Dateien} +\begin{lstlisting} +#!/bin/sh -\subsection*{Unterrichts-Ablauf} +ls -1 > dateiliste.txt -Hinweise zur Präsentation, Zeitplanung, etc. +while read dateiname +do + if [ -d $dateiname ] + then + echo "$dateiname ist ein Verzeichnis" + fi +done < dateiliste.txt -\subsection*{Übungen bei vorhandener Hardware} +\end{lstlisting} +\end{frame} -Hinweise zu Übungen, Zeitlimit dazu. \end{document} -- cgit v1.2.3 From 088976ed259b779438aad64b0997b6bdde5169d4 Mon Sep 17 00:00:00 2001 From: Jan Altenberg Date: Sat, 20 Jun 2009 00:34:08 +0200 Subject: Commit missing RT basics changes --- realtime/rt-basics/handout_rt-basics_de.tex | 168 +++++++++++++++++++++- realtime/rt-basics/hints_rt-basics_de.tex | 13 +- realtime/rt-basics/pres_rt-basics_de.tex | 210 ++++++++++++++++++++++++++-- 3 files changed, 369 insertions(+), 22 deletions(-) diff --git a/realtime/rt-basics/handout_rt-basics_de.tex b/realtime/rt-basics/handout_rt-basics_de.tex index 4c391b2..8576b7d 100644 --- a/realtime/rt-basics/handout_rt-basics_de.tex +++ b/realtime/rt-basics/handout_rt-basics_de.tex @@ -1,17 +1,173 @@ -\documentclass{article} +\documentclass{lxarticle} \usepackage{german} \usepackage[utf8]{inputenc} +\usepackage{lxheaders} +\usepackage{lxextras} \begin{document} -\section*{Titel} +\section*{Realtime Linux} -\subsection*{Abschnitt1} +\subsection*{Grundlagen} -Text +\subsubsection*{Was ist Echteit?} +Vor der Betrachtung verschiedener Ansätze, Linux echtzeitfähig zu machen, ist es +notwendig einige grundlegende Begrifflichkeiten zur erläutern: +\begin{itemize} +\item Echtzeit: +Zur Definition eines Echtzeitsystems kann man folgende Aussagen Treffen: Auf +einem Echtzeitsystem hängt die Korrektheit einer Berechnung nicht nur von deren +logischen Korrektheit, sondern auch von der Ausführung zum korrekten Zeitpunkt +ab. Das Nichteinhalten eines bestimmten Zeitrahmens resultiert in einem Fehler. +\item Latenzzeit: Unter Latenzzeit versteht man den Zeitraum zwischen dem +Auftreten eines Events und der Reaktion auf dieses Event. +\item Jitter: Mit Jitter bezeichnet man die Varianz der Latenzzeit. +\end{itemize} -\subsection*{Abschnitt2} +\subsubsection*{Anwendungsbereiche} +Die wohl gängigsten Anwendungsbereiche für Echtzeitsysteme sind die +Steuerungs- und Automatisierungstechnik, Multimediasysteme und die Luft- und +Raumfahrttechnik. Ein weiteres interessantes Einsatzgebiet stellt die +Finanzdienstleistung dar. Hier geht es insbesondere um die zeitgenaue, +zuverlässige Abwicklung von Finanztransaktionen über hochverteilte Systeme. -Text +\subsubsection*{Anforderungen an ein Echtzeitsystem} +Ein Echtzeitsystem muß in der Lage sein, in einem garantierten Zeitrahmen auf +ein Ereignis zu reagieren. Es muß also möglich sein, in möglichst kurzer Zeit +von einer niederprioren Task auf eine hochpriore Task umzuschalten, falls diese +Rechenzeit benötigt. Das System muß also möglichst ''feingranular'' +unterbrechbar sein. +Doch allein die Unterbrechbarkeit kann kein deterministisches Zeitverhalten +garantieren. So kann eine niederpriore Task Resourcen blockieren, die von einer +hochprioren Task benötigt werden. Wird die niederpriore Task nun unterbrochen, +kommt es zur ''Prioritätsinversion / priority inversion'', da die hochpriore Task +auf die Freigabe der Resource wartet, diese aber erst wieder dann freigegeben +wird, wenn die niederpriore Task wieder Rechenzeit bekommt. +Gelöst werden kann dieses Problem durch ''prioriy inheritance'' und ''priority ceiling''. +\begin{itemize} +\item Prioritätsvererbung / priority inheritance: Hier wird die Priorität der +niederprioren Task angehoben, um zu erreichen, daß die blockierte Resource +freigegeben kann. +\item Prioritätsgrenzen / priority ceiling: Hier wird für jede Resource eine +Prioritätsgrenze festgelegt. Jede Task, die die Resource belegt, wird auf die +Prioritätsgrenze der Resource angehoben. +\end{itemize} + +\subsection*{Realtime Linux Varianten} +\subsubsection*{Historisches zu Echtzeitlinux} +Im Gegensatz zu traditionellen Echtzeitsystem wurde Linux ursprünglich nicht als +solches designt. Als General Purpose Operating System wurde Linux auf Fairness +und Durchsatz optimiert. Linux echtzeitfähig zu machen, bedeutet also, ein +Standardbetriebssystem um Echtzeitfunktionen bzw. entsprechende Sonderfälle zu +erweitern. Mit dieser Tatsache lassen sich die zwei technischen Ansätze für +Realtime Linux erklären. +\begin{itemize} +\item Dual Kernel Ansatz: Hier koexistieren ein Echtzeitkernel, der für alle +zeitkritischen Dinge zuständig ist, und ein Standard Linux Kernel. Dieser Ansatz +setzt voraus, daß alle externen Events zuerst vom Echtzeitkernel bearbeitet +werden, bevor Sie an den Linux Kernel weitergereicht werden können. Die +bekanntesten Vertreter dieser Technik sind RTAI und Xenomai. +\item In-Kernel Ansatz: Diese Methode macht Linux an sich zu einem +Echtzeitsystem. Dieser Ansatz wird mit dem Realtime Preemption Patch verfolgt +und ist die Variante, die von den Linux Entwicklern zur Integration in den +Hauptzweig von Linux abgenickt wurde. +\end{itemize} + +\subsubsection*{RTAI} +Das Realtime Application Interface (RTAI) ist eine Entwicklung der Technischen +Universität Mailand und entstand unter der Schirmherrschaft von Professor Paolo +Mantegazza. Oberstes Designziel von RTAI ist und war es, die kleinstmöglichen +Latenzzeiten auf einer gegebenen Hardwareplattform zu erzielen. Dieses +Designziel bedingt diverse Einschränkungen für RTAI Applikationen. Weiterhin +wird nur eine recht kleine Anzahl an Zielplattormen unterstützt (derzeit x86, +x86\_64 und diverse ARM Plattformen). +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/rtai.png} +\caption{Technischer Aufbau von RTAI} +\label{img:rtai} +\end{figure} +RTAI ist ein typischer Vertreter des Dual Kernel Ansatzes. Abbildung +\ref{img:rtai} zeigt die Funktionsweise von RTAI. + +\subsubsection*{Xenomai} +Das Xenomai Projekt wurde im Jahre 2001 gegründet. Im Gegensatz zu RTAI erlaubt +Xenomai auch Echtzeit im Userpace (RTAI erlaubt dies nur sehr eingeschränkt). +Die Besonderheit von Xenomai sind die sogenannten Skins, die es vereinfachen sollen, +Applikationen von proprietären Echtzeitsystemen nach Xenomai zu portieren. +Xenomai Skins bilden die API dieser Systeme ab. Xenomai unterstützt derzeit +folgende Architekturen: PowerPC32, PowerPC64, x86, x86\_64, Blackfin, ARM und +ia64). Die zentralen Begriffe im Designkonzept von Xenomai stellen Xenomai +Nucleus, die Interrupt Pipeline (IPIPE), Hardware Abstraction Layer (HAL) und +System Abstraction Layer (SAL) dar. +IPIPE kann bildlich als virtueller Interruptkontroller betrachtet werden. +Sie organisiert das System in verschiedenen Domains. Interrupts werden von +IPIPE entgegengenommen und an die einzelnen Domains verteilt. +Nucleus beeinhaltet die Xenomai Core Funktionalität. Dieser ist zuständig dafür, +alle notwendigen Resourcen, die Skins benötigen, um die Funktionalität von +RTOSsen nachzubilden. Der Hardware Abstraction Layer beinhaltet den Plattform +und CPU abhängigen Code. Alle darüberliegenden Layer (darunter auch Nucleus) +bauen darauf auf. HAL ist kombiniert mit dem System Abstraction Layer. Dieser +soll die darüberliegenden Layer, wie z.B. Nucleus, noch portierbarer machen. +Abbildung \ref{img:xenomai} zeigt das technische Zusammenspiel der Xenomai +Komponenten. Abbildung \ref{img:ipipe} zeigt die Funktionsweise von IPIPE. +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/xenomai.png} +\caption{Technischer Aufbau von Xenomai} +\label{img:xenomai} +\end{figure} +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/ipipe.png} +\caption{Technische Funktionsweise von IPIPE} +\label{img:ipipe} +\end{figure} + +\subsubsection*{Preempt RT} +Der Realtime Preemption Patch entstand ursprünglich aus Arbeiten von Ingo Molnar +und Thomas Gleixner. Beide sind bis zum heutigen Zeitpunkt die treibenden Kräfte +bei der Entwicklung von Preempt RT. +Im Gegensatz zu RTAI und Xenomai macht Preempt RT den Linux Kernel an sich +echtzeitfähig. Dies wird im Besonderen durch folgende Mechanismen erreicht: +\begin{itemize} +\item Sleeping Spinlocks: Spinlocks werden durch RT Mutexe ersetzt. Raw +Spinlocks ersetzen die Eigenschaft der ursprünglichen Spinlocks. +\item Threaded Interrupt Handlers: Interrupt Handler laufen per Default nicht im +harten Interruptkontext, sondern als Kernelthread. +\end{itemize} +Viele Mechanismen, die ursprünglich in Preempt RT entwickelt wurden, haben +bereits Ihren Weg in den Mainline Linuxzweig gefunden: High Resolution Timer +(Hochauflösende Timer unabhängig vom Scheduler Tick), Priority Inheritance, +generisches Interrupthandling für alle Architekturen und mit 2.6.30 nun auch die +Threaded Interrupt Handler. +Weiterhin hat sich die Linux Entwicklergemeinde bereits 2006 darauf geeinigt, +daß Preempt RT in den Linux Kernel integriert wird. Weiterhin bietet der +Realtime Preempton Patch den großen Vorteil, daß Echtzeitapplikationen als POSIX +Realtime Applikationen geschrieben werden. Es wird keine spezielle API +verwendet. Preempt RT Unterstützt eine Vielzahl von Architekturen (PowerPc, x86, +x86\_64, MIPS, ARM, ...). +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/preempt_rt.png} +\caption{Überblick Preempt RT} +\label{img:preempt_rt} +\end{figure} +Wie Abbildung \ref{img:preempt_rt} zeigt, integriert Preempt RT die +Echtzeitfunktionalität ''natlos'' in den Linux Kernel. Auch die Entwickler +anderer Projekte haben die Vorzüge von Preempt RT bereits erkannt. Die Roadmap +für Xenomai 3 sieht Preempt RT Support vor. Dies würde den Einsatz von Xenomai +Skins auf Preempt RT Kerneln ermgöglichen. + +\subsection*{Kontrollfragen} + +\begin{enumerate} +\item Was sind die wichtigsten Anforderungen an ein Echtzeitsystem? +\item Welche beiden Ansätze gibt es, um Linux echtzeitfähig zu machen? +\item Was sind die bekanntesten Vertreter für Echtzeitlinux und welchen der oben +beschriebenen Ansätze verfolgen Sie? +\item Wird für das Schreiben einer Echtzeitapplikation mit Preempt RT eine +spezielle API benötigt? +\end{enumerate} \end{document} diff --git a/realtime/rt-basics/hints_rt-basics_de.tex b/realtime/rt-basics/hints_rt-basics_de.tex index fd15c6e..11c5c34 100644 --- a/realtime/rt-basics/hints_rt-basics_de.tex +++ b/realtime/rt-basics/hints_rt-basics_de.tex @@ -1,17 +1,18 @@ -\documentclass{article} +\documentclass{lxarticle} \usepackage{german} \usepackage[utf8]{inputenc} +\usepackage{lxheaders} +\usepackage{lxextras} \begin{document} -\section*{Block \lq Grundlagen Realtime\rq} +\section*{Block \lq Was ist Linux?\rq} \subsection*{Lernziele} \begin{itemize} -\item Kennenlernen der verschiedenen Ansätze (RTAI, Xenomai, RT-Preempt) -\item Kennenlernen der Funktion von RT-Preempt -\item Verstehen, wie der RT-Preempt-Patch beschafft und angewendet werden kann -\item Anwendungen, Grenzen, Geschichte von RT-Preempt +\item Lernziel 1 +\item Lernziel 2 +\item Lernziel 3 \end{itemize} \subsection*{Unterrichts-Ablauf} diff --git a/realtime/rt-basics/pres_rt-basics_de.tex b/realtime/rt-basics/pres_rt-basics_de.tex index 07db328..c60f8a5 100644 --- a/realtime/rt-basics/pres_rt-basics_de.tex +++ b/realtime/rt-basics/pres_rt-basics_de.tex @@ -1,24 +1,214 @@ -\documentclass{article} +\documentclass{beamer} +\usetheme{linutronix} \usepackage{german} \usepackage[utf8]{inputenc} +\usepackage{pgf} +\usepackage{graphicx} +\usepackage{lxextras} + +\title{Block \lq Realtime Linux\rq} +\institute{Linutronix GmbH} \begin{document} -\section*{Block \lq Was ist Linux?\rq} +\maketitle + + +% ----- Slide ------------------ +\begin{frame} +\frametitle{Was ist Echtzeit?} +\begin{itemize} +\item Korrektheit bedeutet auch Ausführung zum korrekten Zeitpunkt +\item Nicht Einhalten des korrekten Zeitrahmens führt zu einem Fehler +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Echtzeit ''anschaulich''} +\begin{overprint} +\onslide<1> +\begin{alertblock}{Wir erinnern uns} +Nicht Einhalten des korrekten Zeitrahmens führt zu einem Fehler! +\end{alertblock} +\onslide<2> +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/nuclear.png} +\end{figure} +\end{overprint} +\end{frame} + +\begin{frame} +\frametitle{Anwendungsbereiche} +\begin{itemize} +\item Steuerungs- / Automatisierungstechnik +\item Multimediasysteme +\item Luft- und Raumfahrttechnik +\item Finanzdienstleistung +\item ... +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Anforderungen} +\begin{itemize} +\item Deterministisches Zeitverhalten +\item Unterbrechbarkeit +\item Priority Inheritance / Priority Ceiling +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Priority Inversion} +\begin{figure}[h] +\centering +\includegraphics[width=0.8\textwidth]{images/prio_inv.png} +\end{figure} +\end{frame} + +\begin{frame} +\frametitle{Linux und Echtzeit} +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/gpos_vs_rt.png} +\end{figure} +\end{frame} -\subsection*{Lernziele} +\begin{frame} +\frametitle{Ansätze} \begin{itemize} -\item Lernziel 1 -\item Lernziel 2 -\item Lernziel 3 +\item Dual-Kernel +\item In-Kernel / Single Kernel \end{itemize} +\end{frame} -\subsection*{Unterrichts-Ablauf} +\begin{frame} +\frametitle{Dual-Kernel} +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/dual_kernel.png} +\end{figure} +\end{frame} -Hinweise zur Präsentation, Zeitplanung, etc. +\begin{frame} +\frametitle{Single-Kernel} +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/single_kernel.png} +\end{figure} +\end{frame} + +\begin{frame} +\frametitle{RTAI} +\begin{itemize} +\item Prof. Paolo Mantegazza, Universität Mailand +\item Dual-Kernel Ansatz +\item Echtzeit im Kernelspace +\item Userspace Echtzeittasks nur eingeschränkt möglich +\item Oberstes Designziel: Möglichst niedrige Latenzzeiten +\item Unterstützte Plattformen: x86, x86\_64, einige ARM Plattformen +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{RTAI} +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/rtai.png} +\end{figure} +\end{frame} + +\begin{frame} +\frametitle{Xenomai} +\begin{itemize} +\item Gegründet 2001 +\item Echtzeit im Userpace +\item Skins bilden API verschiedenster RTOSse nach +\item Dual-Kernel Ansatz +\item Unterstützte Plattformen: x86, x86\_64, PowerPC, ARM, ia64 +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Xenomai} +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/xenomai.png} +\end{figure} +\end{frame} + +\begin{frame} +\frametitle{Xenomai / IPIPE} +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/ipipe.png} +\end{figure} +\end{frame} + +\begin{frame} +\frametitle{Drum prüfe, wer sich ewig bindet...} +\begin{overprint} +\onslide<1> +\begin{figure}[h] +\centering +\includegraphics[width=0.8\textwidth]{images/mar01.png} +\end{figure} +\onslide<2> +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/mar02.png} +\end{figure} +\onslide<3> +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/mar03.png} +\end{figure} +\end{overprint} +\end{frame} + +\begin{frame} +\frametitle{Preempt RT} +\begin{itemize} +\item Thomas Gleixner, Ingo Molnar +\item In-Kernel Ansatz +\item Große Entwicklergemeinde +\item Viele Funktionen bereits nach ''Mainline'' Linux übernommen +\item POSIX Realtime +\item Hohe Akzeptanz, vollständige Integration in Linux 2006 beschlossen +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Preempt RT und Mainline} +\textit{''Controlling a laser with Linux is crazy, but everyone in this room is +crazy in his own way. So if you want to use Linux to control an an industrial +welding laser, I have no problem with your using Preempt RT''} - Linus Torvalds +auf dem Kernel Summit 2006 +\end{frame} + +\begin{frame} +\frametitle{Wie macht Preempt RT Linux echtzeitfähig?} +\begin{overprint} +\onslide<1> +\begin{alertblock}{Wir erinnern uns...} +Unterbrechbarkeit ist eine zentrale Anforderung an ein Echtzeitsystem +\end{alertblock} +\onslide<2> +\begin{itemize} +\item Locking Primitiven: Spinlocks werden durch RT Mutexe ersetzt, die schlafen +können. Raw Spinlocks ersetzen die ursprüngliche Spinlock +\item Interrupt Handler laufen per default in einem Kernelthread +\end{itemize} +\end{overprint} +\end{frame} -\subsection*{Übungen bei vorhandener Hardware} +\begin{frame} +\frametitle{Preempt RT} +\begin{figure}[h] +\centering +\includegraphics[height=0.5\textwidth]{images/preempt_rt.png} +\end{figure} +\end{frame} -Hinweise zu Übungen, Zeitlimit dazu. \end{document} -- cgit v1.2.3 From 1a3683c79d847149366c7b45080f204c10ff2431 Mon Sep 17 00:00:00 2001 From: "Hans J. Koch" Date: Sat, 20 Jun 2009 01:59:58 +0200 Subject: Added kernel-devel/kernel-basics --- kernel-devel/kernel-basics/Makefile | 9 ++ .../kernel-basics/handout_kernel-basics_de.tex | 137 ++++++++++++++++++++- .../kernel-basics/pres_kernel-basics_de.tex | 45 +++++-- 3 files changed, 173 insertions(+), 18 deletions(-) create mode 100644 kernel-devel/kernel-basics/Makefile 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..8d11e65 100644 --- a/kernel-devel/kernel-basics/pres_kernel-basics_de.tex +++ b/kernel-devel/kernel-basics/pres_kernel-basics_de.tex @@ -1,24 +1,45 @@ -\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 + + +% ----- Slide ------------------ +\begin{frame} +\frametitle{Kernel-Eigenschaften} +\end{frame} -\subsection*{Lernziele} -\begin{itemize} -\item Lernziel 1 -\item Lernziel 2 -\item Lernziel 3 -\end{itemize} +% ----- Slide ------------------ +\begin{frame} +\frametitle{Aufbau des Kernels} +\centering +\includegraphics[width=0.8\textwidth]{images/Subsystems.png} +\end{frame} -\subsection*{Unterrichts-Ablauf} +% ----- Slide ------------------ +\begin{frame} +\frametitle{Kernel Maintainer} +\end{frame} -Hinweise zur Präsentation, Zeitplanung, etc. +% ----- Slide ------------------ +\begin{frame} +\frametitle{Entwicklungsprozess} +\end{frame} -\subsection*{Übungen bei vorhandener Hardware} +% ----- Slide ------------------ +\begin{frame} +\frametitle{Kernel-Konfiguration} +\end{frame} -Hinweise zu Übungen, Zeitlimit dazu. \end{document} -- cgit v1.2.3 From 885ad2f166b61447f0ebf858a8a8dc84a3fba857 Mon Sep 17 00:00:00 2001 From: "Hans J. Koch" Date: Sat, 20 Jun 2009 02:31:20 +0200 Subject: Updated presentation for kernel-devel/kernel-basics --- .../kernel-basics/pres_kernel-basics_de.tex | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/kernel-devel/kernel-basics/pres_kernel-basics_de.tex b/kernel-devel/kernel-basics/pres_kernel-basics_de.tex index 8d11e65..8b6161e 100644 --- a/kernel-devel/kernel-basics/pres_kernel-basics_de.tex +++ b/kernel-devel/kernel-basics/pres_kernel-basics_de.tex @@ -17,6 +17,29 @@ % ----- Slide ------------------ \begin{frame} \frametitle{Kernel-Eigenschaften} +\begin{itemize} +\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} % ----- Slide ------------------ @@ -29,16 +52,51 @@ % ----- 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} % ----- 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} -- cgit v1.2.3 From d3835cbfea3bbc19b386f31c4972d4bc37b9347b Mon Sep 17 00:00:00 2001 From: "Hans J. Koch" Date: Sat, 20 Jun 2009 03:00:55 +0200 Subject: Added Makefiles in each folder to allow make all or make clean from top level directory --- Makefile | 6 ++++++ application-devel/Makefile | 6 ++++++ kernel-devel/Makefile | 6 ++++++ linux-basics/Makefile | 6 ++++++ realtime/Makefile | 7 +++++++ 5 files changed, 31 insertions(+) create mode 100644 application-devel/Makefile create mode 100644 kernel-devel/Makefile create mode 100644 linux-basics/Makefile create mode 100644 realtime/Makefile diff --git a/Makefile b/Makefile index 4929de1..494db82 100644 --- a/Makefile +++ b/Makefile @@ -1,3 +1,5 @@ +SUBDIRS = kernel-devel linux-basics realtime application-devel + latex-install: mkdir -p /usr/share/texmf-texlive/tex/latex/linutronix cp latex/lxarticle/lxarticle.cls /usr/share/texmf-texlive/tex/latex/linutronix/ @@ -10,3 +12,7 @@ latex-install: cp latex/latex-beamer/*vf /usr/share/texmf/fonts/vf/linutronix texhash +all clean:: + for dir in $(SUBDIRS) ; do \ + (cd $$dir && make $@); \ + done diff --git a/application-devel/Makefile b/application-devel/Makefile new file mode 100644 index 0000000..d62fe78 --- /dev/null +++ b/application-devel/Makefile @@ -0,0 +1,6 @@ +SUBDIRS = app-debugging compile-tools devel-best-practices devel-environment embedded-devel + +all clean:: + for dir in $(SUBDIRS) ; do \ + (cd $$dir && make $@); \ + done 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/linux-basics/Makefile b/linux-basics/Makefile new file mode 100644 index 0000000..ab3b327 --- /dev/null +++ b/linux-basics/Makefile @@ -0,0 +1,6 @@ +SUBDIRS = boot-process filesystem-structure important-tools linux-processes sh-programming what-is-linux + +all clean:: + for dir in $(SUBDIRS) ; do \ + (cd $$dir && make $@); \ + done diff --git a/realtime/Makefile b/realtime/Makefile new file mode 100644 index 0000000..fa8db4f --- /dev/null +++ b/realtime/Makefile @@ -0,0 +1,7 @@ +SUBDIRS = rt-app-basics rt-basics rt-specialties + +all clean:: + for dir in $(SUBDIRS) ; do \ + (cd $$dir && make $@); \ + done + -- cgit v1.2.3 From 3ed5b5306f5fa4ee95bcb5a57733bd116ce008e3 Mon Sep 17 00:00:00 2001 From: Jan Altenberg Date: Sat, 20 Jun 2009 03:36:56 +0200 Subject: Adding one more missing rt-basic file --- realtime/rt-basics/images/mar03.svg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/realtime/rt-basics/images/mar03.svg b/realtime/rt-basics/images/mar03.svg index 25c40ad..71e98ae 100644 --- a/realtime/rt-basics/images/mar03.svg +++ b/realtime/rt-basics/images/mar03.svg @@ -16,7 +16,7 @@ inkscape:version="0.46" sodipodi:docname="mar03.svg" inkscape:output_extension="org.inkscape.output.svg.inkscape" - inkscape:export-filename="/home/jan/work/omnicron/schulung/realtime/rt-basics/images/mar02.png" + inkscape:export-filename="/home/jan/work/omnicron/schulung/realtime/rt-basics/images/mar03.png" inkscape:export-xdpi="90" inkscape:export-ydpi="90"> Date: Sat, 20 Jun 2009 03:38:22 +0200 Subject: rt-specialties chapter --- realtime/rt-specialties/Makefile | 9 + .../rt-specialties/handout_rt-specialties_de.tex | 295 ++++++++++++++++++++- .../rt-specialties/hints_rt-specialties_de.tex | 18 +- realtime/rt-specialties/images/g4894.png | Bin 0 -> 12196 bytes realtime/rt-specialties/images/menu_rt_001.png | Bin 0 -> 30735 bytes realtime/rt-specialties/images/menu_rt_002.png | Bin 0 -> 32309 bytes realtime/rt-specialties/images/menu_rt_003.png | Bin 0 -> 32025 bytes realtime/rt-specialties/images/menu_rt_004.png | Bin 0 -> 23627 bytes realtime/rt-specialties/images/pitfall.png | Bin 0 -> 32291 bytes realtime/rt-specialties/images/pitfall.svg | 121 +++++++++ realtime/rt-specialties/images/thumb.png | Bin 0 -> 12196 bytes realtime/rt-specialties/images/thumb.svg | 86 ++++++ realtime/rt-specialties/pres_rt-specialties_de.tex | 227 +++++++++++++++- 13 files changed, 732 insertions(+), 24 deletions(-) create mode 100644 realtime/rt-specialties/Makefile create mode 100644 realtime/rt-specialties/images/g4894.png create mode 100644 realtime/rt-specialties/images/menu_rt_001.png create mode 100644 realtime/rt-specialties/images/menu_rt_002.png create mode 100644 realtime/rt-specialties/images/menu_rt_003.png create mode 100644 realtime/rt-specialties/images/menu_rt_004.png create mode 100644 realtime/rt-specialties/images/pitfall.png create mode 100644 realtime/rt-specialties/images/pitfall.svg create mode 100644 realtime/rt-specialties/images/thumb.png create mode 100644 realtime/rt-specialties/images/thumb.svg diff --git a/realtime/rt-specialties/Makefile b/realtime/rt-specialties/Makefile new file mode 100644 index 0000000..e80961b --- /dev/null +++ b/realtime/rt-specialties/Makefile @@ -0,0 +1,9 @@ +all: + pdflatex pres_rt-specialties_de.tex + pdflatex hints_rt-specialties_de.tex + pdflatex handout_rt-specialties_de.tex + pdflatex handout_rt-specialties_de.tex + +clean: + rm -f *.aux *.log *.pdf *.log *.snm *.toc *.vrb *.nav *.out + diff --git a/realtime/rt-specialties/handout_rt-specialties_de.tex b/realtime/rt-specialties/handout_rt-specialties_de.tex index 4c391b2..372aa25 100644 --- a/realtime/rt-specialties/handout_rt-specialties_de.tex +++ b/realtime/rt-specialties/handout_rt-specialties_de.tex @@ -1,17 +1,300 @@ -\documentclass{article} +\documentclass{lxarticle} \usepackage{german} \usepackage[utf8]{inputenc} +\usepackage{lxheaders} +\usepackage{lxextras} \begin{document} -\section*{Titel} +\section*{Anwendung des Preempt RT Patches} +\subsection*{Besorgen und Anwenden des Patches} +Preempt RT wird als Patch gegen den Mainline Linux Kernel gepflegt. +Unter:\newline +http://www.kernel.org/pub/linux/kernel/projects/rt sind die aktuellsten Patche +für Preempt RT zu finden. Im Unterverzeichnis older/ sind ältere Patche +archiviert. Das Vorbereiten eines Kerneltrees mit Preempt RT ist denkbar +einfach: +\begin{lstlisting} +# Vanilla Kernel +wget http://www.kernel.org/pub/linux/kernel\ +/v2.6/linux-2.6.29.5.tar.bz2 -\subsection*{Abschnitt1} +# Preempt RT Patch +wget http://www.kernel.org/pub/linux/kernel\ +/projects/rt/patch-2.6.29.5-rt21.bz2 -Text +# Extract the kernel tree +tar xjvf linux-2.6.29.5.tar.bz2 +# Patch the kernel tree +cd linux-2.6.29.5 +bzcat ../patch-2.6.29.5-rt21.bz2 | patch -p1 +\end{lstlisting} +Mit Steven Rostedt's Version des Pythonskripts ''ketchup'' geht es sogar noch einfacher (Steven +Rostedt's ketchup Version steht unter:\newline +http://people.redhat.com/srostedt/rt/tools/ketchup-0.9.8-rt3 zum Download +bereit): +\begin{lstlisting} +mkdir linux-2.6.29.5-rt21 +cd linux-2.6.29.5-rt21 +ketchup -f --no-gpg 2.6.29.5-rt21 +\end{lstlisting} -\subsection*{Abschnitt2} +\subsection*{Konfigurieren und Übersetzen eines Preempt RT Kernels} +Die Konfiguration und das Übersetzen machen keinen Unterschied zu Linux ohne +Preempt RT Patch: +\begin{lstlisting} +# external build directory +mkdir ../build +# base build on existing config +cp /boot/config-x-x-x ../build/.config +make O=../build oldconfig +\end{lstlisting} +Für ein Echtzeitsystem müssen verschiedene Kerneloptionen aktiviert werden: +\begin{lstlisting} +make O=../build menuconfig +\end{lstlisting} +Die wichtigsten Optionen befinden sich unter dem Menupunkt ''Kernel features'' +bzw. ''Processor type and features''. +\begin{figure}[ht!] +\centering +\includegraphics[height=0.5\textwidth]{images/menu_rt_001.png} +\end{figure} +Dort müssen folgende Optionen aktiviert werden: +\begin{itemize} +\item High Resolution Timer Support +\item Preemption Mode (Complete Preemption (Real-Time)) +\end{itemize} +\begin{figure}[ht!] +\centering +\includegraphics[height=0.5\textwidth]{images/menu_rt_002.png} +\end{figure} +\begin{figure}[ht!] +\centering +\includegraphics[height=0.5\textwidth]{images/menu_rt_003.png} +\end{figure} +\begin{figure}[ht!] +\centering +\includegraphics[height=0.5\textwidth]{images/menu_rt_004.png} +\end{figure} +Das Übersetzen des Kernels erfolgt nun wie üblich mit +\begin{lstlisting} +make O=../build +make O=../build modules +make O=../build install +make O=../build modules_install +\end{lstlisting} +\section*{Testen eines Preempt RT Systems} +\subsection*{RT Tests} +Die RT Tests sind eine Sammlung von Programmen, zur Validierung der +Eigenschaften von Echtzeitsystemen. Die RT Tests umfassen folgende Tools: +\begin{itemize} +\item cyclictest: High Resolution Timer Testsoftware. +\item hwlatdetect: Python Script, zur Steuerung des Kernelmoduls zur Erkennung +von System Management Interrupts (hwlat\_detector). +\item pi\_stress: Stresstest für Mutexe mit Priority Inheritance Attribut +\item signaltest: Benchmark, bei dem Signale zwischen Tasks ausgetauscht werden. +\end{itemize} +Die Sourcen der RT Tests werden in einem GIT Tree verwaltet. +\begin{lstlisting} +# Checkout RT Tests +git-clone git://git.kernel.org/pub/scm/linux/kernel\ +/git/clrkwllms/rt-tests.git -Text +# Compile RT Tests +cd rt-tests +make +\end{lstlisting} +\subsection*{Cyclictest} +Cyclictest ist die wohl meistgenutzte Testsoftware auf Preempt RT Systemen. Mit +Cyclictest kann eine bestimmte Anzahl von Timertasks mit einem definierten +Interval aufgesetzt werden. Für diese Tasks wird kontinuierlich die Abweichung +zum gewünschten Interval gemessen und hierfür die Maximale und Durchschnittliche +Abweichung aufgezeichnet. Die wichtigsten Parameter für Cyclictest sind die +Anzahl und die Priorität der gewünschten Timertasks, die Art des zu verwendenden +Timers und das gewünschte Timerinterval: +\begin{lstlisting} +# 4 Timertasks (2000 , 2500, 3000, 3500us) +# -i options tells us the interval of the first task +# the interval of all other tasks will be increased +# by 500us +# The -p options tells us the priority of the first task +# the priorities of all other tasks will be decremented by 1 +# -n = using nanosleep +zi:~# cyclictest -p80 -n -t4 -i2000 +0.32 0.30 0.12 1/56 2124 +T: 0 ( 2121) P:80 I:2000 C: 1258 Min: 62 Act: 99 Avg: 83 Max: 161 +T: 1 ( 2122) P:79 I:2500 C: 1007 Min: 47 Act: 76 Avg: 77 Max: 130 +T: 2 ( 2123) P:78 I:3000 C: 841 Min: 54 Act: 76 Avg: 82 Max: 136 +T: 3 ( 2124) P:77 I:3500 C: 723 Min: 67 Act: 95 Avg: 96 Max: 177 +\end{lstlisting} +\subsection*{Lastszenarien} +Um eine Aussage über das Echtzeitverhaltens treffen zu können, interessiert in +der Hauptsache das Verhalten in Worst-Case Szenarien (hohe CPU Laste, hohe +Interruptlast). Ein ausgezeichnetes Werkzeug, um CPU Last zu erzeugen, ist +''hackbench''. Hackbench wurde ursprünglich als Schedulerbenchmark entwickelt. +Es erzeugt eine bestimme Anzahl an Prozessgruppen von Clients und Servern, die +über Sockets miteinander kommunizieren:\newline +http://people.redhat.com/mingo/cfs-scheduler/tools/hackbench.c + +Interruptlast, läßt sich hervorragend mit einem Floodping von einem entfernten +Rechner erzeugen. Ein Floodping schickt eine große Anzahl von ICMP Paketen in +kurzer Zeit. Dies erzeugt eine hohe Anzahl von Netzwerkinterrupts. Um Floodpings +zu generieren muß das Programm ping mit Rootrechten und mit der Option -f +ausgeführt werden. +\subsection*{Pitfall} +Ein sehr häufig gemeldetes Phänomen bei Testläufen von Cyclictest mit einem +Floodping als Lastszenario, sind extrem große Ausreißer in der Größenordnung von +50ms. Dies ist auf ein ''Feature'' aktueller Preempt RT Kernel zurückzuführen. +Da Preempt RT auch auf vielen Desktops eingesetzt wird, auf denen Low Latency +Anwendungen betrieben werden (z.B. Multimedia Anwendungen), häuften sich +Fehlerberichte, die letztendlich nicht auf ein Kernelproblem zurückzuführen +waren, sondern auf eine Realtime Applikation, die den Rest des Systems +aushungerte. Daher wurde eine Option eingeführt, die die Laufzeit von Realtime +Tasks beschränken kann. Überschreiten die Realtime Tasks dieses Zeitlimit, +werden diese für einen bestimmten Zeitraum nicht mehr geschedult. Die +Standardeinstellung liegt bei 950ms. Bei Überschreiten der 950ms werden die +Echtzeittasks für 50ms suspendiert. Dieser Wert kann durch Schreiben des +gewünschten Wertes nach /proc/sys/kernel/sched\_rt\_runtime\_us angepaßt werden. +Zum Deaktivieren dieser Funktion muß folgendes getan werden: +\begin{lstlisting} +echo -1 > /proc/sys/kernel/sched_rt_runtime_us +\end{lstlisting} +\section*{Erstellen einer Realtime Task für Preempt RT} +\subsection*{Schedulingklassen / Prioritäten} +Eine Realtime Applikation auf Preempt RT ist eine POSIX Realtime Applikation. +POSIX sieht für Echtzeitapplikationen folgende Schedulingstrategien vor: +\begin{itemize} +\item SCHED\_FIFO: Scheduling mit statischen Prioriäten +\item SCHED\_RR: Round Robin mit Prioritäten +\end{itemize} +Echtzeitpriorität bekommt eine Applikation nur dann, wenn dies explizit +gewünscht wird. Hierzu ist die Funktion sched\_setscheduler() vorgesehen. +\subsection*{Beispiel einer Echtzeitapplikation} +Das folgende Beispiel zeigt eine einfache POSIX Realtimeapplikation: +\begin{lstlisting} +/* + * POSIX Realtime Example + * based on the example on http://rt.wiki.kernel.org + / +#include +#include +#include +#include +#include +#include + +#define MAX_SAFE_STACK (8*1024) /* The maximum stack size which is + guranteed safe to access without + faulting */ + +void stack_prefault(void) { + + unsigned char dummy[MAX_SAFE_STACK]; + + memset(&dummy, 0, MAX_SAFE_STACK); + return; +} + +int main(int argc, char* argv[]) +{ + struct sched_param param; + + /* Declare ourself as a real time task */ + param.sched_priority = 80; + if(sched_setscheduler(0, SCHED_FIFO, ¶m) == -1) { + perror("sched_setscheduler failed"); + exit(-1); + } + + /* Lock memory !!!*/ + if(mlockall(MCL_CURRENT|MCL_FUTURE) == -1) { + perror("mlockall failed"); + exit(-2); + } + + /* Pre-fault our stack */ + stack_prefault(); + + while(1) { + [...] + } +} +\end{lstlisting} +Die oben aufgelistete Applikation zeigt sehr schön, was notwendig ist, um eine +Applikation mit deterministischem Zeitverhalten zu erzeugen: +\begin{itemize} +\item RT Scheduling Policy und Priorität festlegen +\item Speicher locken, um zu vermeiden, um undeterministisches Zeitverhalten +durch Pagefaults auszuschliessen. +\item ''Stack Pre-Faulting'', um zu zu vermeiden, daß Stackfaults +undeterministisches Zeitverhalten verursachen +\end{itemize} +Eine Ausgezeichnete Einführung zum Erstellen von Echtzeitapplikation und zur +Verwendung von Preempt RT, findet sich unter:\newline +http://rt.wiki.kernel.org +\subsection*{Tracing / Latenzen aufspüren} +\subsubsection*{FTrace} +Ein hervorragendes Werkzeug, um kernelseitige Codepfade aufzuspüren, die lange +Latenzzeiten verursachen, ist Ftrace. Ftrace wird über DebugFS, einem virtuellen +Dateisystem, gesteuert und platziert dort auch seine Ausgaben. Die einfachste +Methode, FTrace zu verwenden ist Cyclictest. Cyclictest biete bereits einige +Optionen, um FTrace zu verwenden. Die Option -f schällt Cyclictests Ftrace +Support an, -b veranlaßt Cyclictest, bei Überschreiten einer +maximalen Latenzzeit, abzubrechen und einen Trace zu triggern. +\subsubsection*{Kerneloptionen für FTrace} +Um FTrace verwenden zu können, müssen beim Konfigurieren des Kernel einige +unter dem Menupunkt ''Kernel hacking-->Tracers'' einige Optionen aktiviert werden: +\begin{itemize} +\item Kernel Function Tracer +\item Optional: Beliebige Optionen, die mit Trace beginnen (der zu verwendende +Tracetyp kann cyclictest über die Commandline mitgegeben werden, siehe +cyclictest -h. Default ist der +Event Tracer) +\end{itemize} +\subsubsection*{Beispiel eines Traces} +Das Erstellen eines Traces mit cyclictest läßt sich am Besten mit einem Beispiel +erläutern: +\begin{lstlisting} +# mount DebugFS +mkdir -p /mnt/debugfs +mount -t debugs debugfs /mnt/debugfs + +# list available tracers +zi:~# cat /mnt/debugfs/tracing/available_tracers +wakeup_rt wakeup preemptoff function sched_switch nop + +# start trace +cyclictest -p80 -n -f -b 100 + +zi:~# less /mnt/debugfs/tracing/trace +# tracer: function +# +# TASK-PID CPU# TIMESTAMP FUNCTION +# | | | | | +IRQ-129-772 [000] 4154503386.851178: __rt_mutex_adjust_prio<-t +IRQ-129-772 [000] 4154503386.851186: __rt_mutex_adjust_prio<-t +IRQ-129-772 [000] 4154503386.851189: task_setprio<-__rt_mutex_ +IRQ-129-772 [000] 4154503386.851192: task_rq_lock <-task_setpr +IRQ-129-772 [000] 4154503386.851195: sched_clock <-sched_clock +IRQ-129-772 [000] 4154503386.851199: dequeue_task <-task_setpr +IRQ-129-772 [000] 4154503386.851202: dequeue_task_fair <-deque +IRQ-129-772 [000] 4154503386.851206: update_curr <-dequeue_tas +IRQ-129-772 [000] 4154503386.851217: enqueue_task_rt <-task_se +IRQ-129-772 [000] 4154503386.851221: dequeue_rt_stack<-enqueue +IRQ-129-772 [000] 4154503386.851226: switched_to_rt <-task_set +IRQ-129-772 [000] 4154503386.851234: timer_interrupt<-ret_from +[...] +\end{lstlisting} + +\subsection*{Kontrollfragen} +\begin{itemize} +\item Welche Optionen sollten beim Übersetzen eines Preempt RT Kernels +mindestens gesetzt sein? +\item Wozu dient das Tool cyclictest? +\item Welchen bekannten ''Pitfall'' gibt es bzgl. hoher Latencies mit Floodping +als Lastszenario? Wie kann dieser behoben werden? +\item Welche 3 Schritte sind notwendig, um das deterministische Zeitverhalten +einer Applikation zu garantieren? +\end{itemize} \end{document} diff --git a/realtime/rt-specialties/hints_rt-specialties_de.tex b/realtime/rt-specialties/hints_rt-specialties_de.tex index b8b74bc..e07f25a 100644 --- a/realtime/rt-specialties/hints_rt-specialties_de.tex +++ b/realtime/rt-specialties/hints_rt-specialties_de.tex @@ -1,25 +1,27 @@ -\documentclass{article} +\documentclass{lxarticle} \usepackage{german} \usepackage[utf8]{inputenc} +\usepackage{lxheaders} +\usepackage{lxextras} \begin{document} -\section*{Block \lq Realtime-Besonderheiten\rq} +\section*{Block \lq Was ist Linux?\rq} \subsection*{Lernziele} \begin{itemize} -\item Verstehen, warum Kernel-Treiber SMP-fest sein müssen -\item Kennenlernen der Grundregeln für korrektes Locking im Kernel -\item Kennenlernen von Möglichkeiten zum Test der RT-Funktionalität - (lockdep, cyclictest) +\item Beschaffen und anwenden des Preempt RT Patches +\item Konfigurieren und Kompilieren eines Preempt RT Kernels +\item Testen des Preempt RT Kernels \end{itemize} \subsection*{Unterrichts-Ablauf} -Hinweise zur Präsentation, Zeitplanung, etc. +Vortrag + Übungen (insgesamt 90 - 120 Minuten) \subsection*{Übungen bei vorhandener Hardware} -Hinweise zu Übungen, Zeitlimit dazu. +RT Kernel für das Entwicklungssystem. Testen des RT Kernels und dessen +Echtzeitverhaltens auf dem Entwicklungssystem. \end{document} diff --git a/realtime/rt-specialties/images/g4894.png b/realtime/rt-specialties/images/g4894.png new file mode 100644 index 0000000..6b9f247 Binary files /dev/null and b/realtime/rt-specialties/images/g4894.png differ diff --git a/realtime/rt-specialties/images/menu_rt_001.png b/realtime/rt-specialties/images/menu_rt_001.png new file mode 100644 index 0000000..27f26cd Binary files /dev/null and b/realtime/rt-specialties/images/menu_rt_001.png differ diff --git a/realtime/rt-specialties/images/menu_rt_002.png b/realtime/rt-specialties/images/menu_rt_002.png new file mode 100644 index 0000000..c4dd8dc Binary files /dev/null and b/realtime/rt-specialties/images/menu_rt_002.png differ diff --git a/realtime/rt-specialties/images/menu_rt_003.png b/realtime/rt-specialties/images/menu_rt_003.png new file mode 100644 index 0000000..8449d80 Binary files /dev/null and b/realtime/rt-specialties/images/menu_rt_003.png differ diff --git a/realtime/rt-specialties/images/menu_rt_004.png b/realtime/rt-specialties/images/menu_rt_004.png new file mode 100644 index 0000000..21045c8 Binary files /dev/null and b/realtime/rt-specialties/images/menu_rt_004.png differ diff --git a/realtime/rt-specialties/images/pitfall.png b/realtime/rt-specialties/images/pitfall.png new file mode 100644 index 0000000..a083003 Binary files /dev/null and b/realtime/rt-specialties/images/pitfall.png differ diff --git a/realtime/rt-specialties/images/pitfall.svg b/realtime/rt-specialties/images/pitfall.svg new file mode 100644 index 0000000..bdfc4de --- /dev/null +++ b/realtime/rt-specialties/images/pitfall.svg @@ -0,0 +1,121 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + diff --git a/realtime/rt-specialties/images/thumb.png b/realtime/rt-specialties/images/thumb.png new file mode 100644 index 0000000..6b9f247 Binary files /dev/null and b/realtime/rt-specialties/images/thumb.png differ diff --git a/realtime/rt-specialties/images/thumb.svg b/realtime/rt-specialties/images/thumb.svg new file mode 100644 index 0000000..9dd0510 --- /dev/null +++ b/realtime/rt-specialties/images/thumb.svg @@ -0,0 +1,86 @@ + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + diff --git a/realtime/rt-specialties/pres_rt-specialties_de.tex b/realtime/rt-specialties/pres_rt-specialties_de.tex index 07db328..e7e3d1d 100644 --- a/realtime/rt-specialties/pres_rt-specialties_de.tex +++ b/realtime/rt-specialties/pres_rt-specialties_de.tex @@ -1,24 +1,231 @@ -\documentclass{article} +\documentclass{beamer} +\usetheme{linutronix} \usepackage{german} \usepackage[utf8]{inputenc} +\usepackage{pgf} +\usepackage{graphicx} +\usepackage{lxextras} + +\title{Block \lq Anwendung des Preempt RT Patches\rq} +\institute{Linutronix GmbH} \begin{document} -\section*{Block \lq Was ist Linux?\rq} +\maketitle + + +% ----- Slide ------------------ +\begin{frame}[fragile] +\frametitle{Besorgen und Anwenden des Preempt RT Patches} +\begin{lstlisting} +# Vanilla Kernel +wget http://www.kernel.org/pub/linux/kernel\ +/v2.6/linux-2.6.29.5.tar.bz2 + +# Preempt RT Patch +wget http://www.kernel.org/pub/linux/kernel\ +/projects/rt/patch-2.6.29.5-rt21.bz2 + +# Extract the kernel tree +tar xjvf linux-2.6.29.5.tar.bz2 +# Patch the kernel tree +cd linux-2.6.29.5 +bzcat ../patch-2.6.29.5-rt21.bz2 | patch -p1 +\end{lstlisting} +\end{frame} + +\begin{frame}[fragile] +\frametitle{Besorgen und Anwenden des Preempt RT Patches} +\begin{lstlisting} +mkdir linux-2.6.29.5-rt21 +cd linux-2.6.29.5-rt21 +ketchup -f --no-gpg 2.6.29.5-rt21 +\end{lstlisting} +\end{frame} -\subsection*{Lernziele} +\begin{frame}[fragile] +\frametitle{Konfigurieren und Übersetzen eines Preempt RT Kernels} +\begin{overprint} +\onslide<1> +\begin{lstlisting} +# external build directory +mkdir ../build +# base build on existing config +cp /boot/config-x-x-x ../build/.config +make O=../build oldconfig +\end{lstlisting} +\onslide<2> +\begin{lstlisting} +make O=../build menuconfig +\end{lstlisting} +\onslide<3> +\begin{figure}[ht!] +\centering +\includegraphics[height=0.5\textwidth]{images/menu_rt_001.png} +\end{figure} +\onslide<4> +\begin{figure}[ht!] +\centering +\includegraphics[height=0.5\textwidth]{images/menu_rt_002.png} +\end{figure} +\onslide<5> +\begin{figure}[ht!] +\centering +\includegraphics[height=0.5\textwidth]{images/menu_rt_003.png} +\end{figure} +\onslide<6> +\begin{figure}[ht!] +\centering +\includegraphics[height=0.5\textwidth]{images/menu_rt_004.png} +\end{figure} +\onslide<7> +\begin{lstlisting} +make O=../build +make O=../build modules +make O=../build install +make O=../build modules_install +\end{lstlisting} +\end{overprint} +\end{frame} + +\begin{frame} +\frametitle{Testen eines Preempt RT Systems} +RT Tests: \begin{itemize} -\item Lernziel 1 -\item Lernziel 2 -\item Lernziel 3 +\item cyclictest +\item hwlatdetect +\item pi\_stress +\item signaltest \end{itemize} +\end{frame} -\subsection*{Unterrichts-Ablauf} +\begin{frame} +\frametitle{Cyclictest} +\begin{itemize} +\item Ursprünglich entwickelt von Thomas Gleixner für Preempt RT Testing +\item High Resolution Timer Testsoftware +\item Setzt beliebige Anzahl von Realtime Tasks mit unterschiedlicher Priorität +und unterschiedlichen Intervallen auf +\item Viele Debuggingmöglichkeiten +\item Sehr Aussagekräftig, um echtzeitverhalten auf einer bestimmten Plattform +zu beurteilen. +\end{itemize} +\end{frame} -Hinweise zur Präsentation, Zeitplanung, etc. +\begin{frame} +\frametitle{Lastszenarien} +Geeignete Lastszenarien, um Worst-Case Situationen nachstellen /provozieren zu +können: +\begin{itemize} +\item CPU Last: ''hackbench'', ursprünglich als Scheduler Benchmark geschrieben. +\item Interrupt Last: Floodping (''ping -F'') +\end{itemize} +\end{frame} + +\begin{frame}[fragile] +\frametitle{Pitfall!} +\begin{lstlisting} +cat /proc/sys/kernel/sched_rt_runtime_us +\end{lstlisting} +\begin{figure}[l!] +\centering +\includegraphics[height=0.4\textwidth]{images/pitfall.png} +\end{figure} +\end{frame} + +\begin{frame} +\frametitle{Echtzeitapplikationen mit Preempt RT} +\begin{columns} +\column[r]{7cm} +\begin{figure}[l!] +\centering +\includegraphics[height=0.4\textwidth]{images/thumb.png} +\end{figure} +\column[l]{8cm} +\huge +POSIX! +\end{columns} +\end{frame} + +\begin{frame} +\frametitle{Schedulingstrategien} +\begin{itemize} +\item SCHED\_FIFO: Static priority +\item SCHED\_RR: Round Robin mit Prioritäten +\end{itemize} +\end{frame} + +\begin{frame}[fragile] +\frametitle{Aufbau einer RT Applikation} +\begin{overprint} +\onslide<1> +Schedulingstrategie / Priorität +\begin{lstlisting} +struct sched_param param; + +param.sched_priority = 80; +if(sched_setscheduler(0, SCHED_FIFO, ¶m) + == -1) { + perror("sched_setscheduler failed"); + exit(-1); +} +\end{lstlisting} +\onslide<2> +Lock memory: +\begin{lstlisting} +if(mlockall(MCL_CURRENT|MCL_FUTURE) == -1) { + perror("mlockall failed"); + exit(-2); +} +\end{lstlisting} +\onslide<3> +''Stack prefaulting'' +\begin{lstlisting} +void stack_prefault(void) { + unsigned char dummy[MAX_SAFE_STACK]; + memset(&dummy, 0, MAX_SAFE_STACK); + return; +} +\end{lstlisting} +\end{overprint} +\end{frame} + +\begin{frame}[fragile] +\frametitle{Tracing / Latency hunting} +\begin{itemize} +\item FTrace +\item Cyclictest unterstützt Traces mittels FTrace +\item Unterschiedliche Tracer (müssen im Kernel aktiviert sein) +\item Kommunikation mit FTrace über Debugfs +\end{itemize} +\end{frame} -\subsection*{Übungen bei vorhandener Hardware} +\begin{frame}[fragile] +\frametitle{Cyclictest + FTrace} +\begin{lstlisting}[basicstyle=\ttfamily\fontsize{8}{10}\selectfont] +# mount DebugFS +mkdir -p /mnt/debugfs +mount -t debugs debugfs /mnt/debugfs -Hinweise zu Übungen, Zeitlimit dazu. +# list available tracers +zi:~# cat /mnt/debugfs/tracing/available_tracers +wakeup_rt wakeup preemptoff function sched_switch nop +\end{lstlisting} +\end{frame} +\begin{frame}[fragile] +\frametitle{Cyclictest + FTrace} +\begin{lstlisting}[basicstyle=\ttfamily\fontsize{8}{10}\selectfont] +cyclictest -p80 -n -f -b 100 +zi:~# less /mnt/debugfs/tracing/trace +# tracer: function +# +# TASK-PID CPU# TIMESTAMP FUNCTION +# | | | | | +IRQ-129-772 [000] 4154503386.851178: __rt_mutex_adjust_prio +IRQ-129-772 [000] 4154503386.851186: __rt_mutex_adjust_prio +IRQ-129-772 [000] 4154503386.851189: task_setprio<-__rt_mut +[...] +\end{lstlisting} +\end{frame} \end{document} -- cgit v1.2.3 From 4f259a1216b52bf0341ec30544e068e49cec4895 Mon Sep 17 00:00:00 2001 From: Jan Altenberg Date: Sat, 20 Jun 2009 12:10:29 +0200 Subject: RT basics fixes --- realtime/rt-basics/handout_rt-basics_de.tex | 22 +++++++++++----------- realtime/rt-basics/pres_rt-basics_de.tex | 2 +- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/realtime/rt-basics/handout_rt-basics_de.tex b/realtime/rt-basics/handout_rt-basics_de.tex index 8576b7d..8d98ccc 100644 --- a/realtime/rt-basics/handout_rt-basics_de.tex +++ b/realtime/rt-basics/handout_rt-basics_de.tex @@ -10,13 +10,13 @@ \subsection*{Grundlagen} -\subsubsection*{Was ist Echteit?} +\subsubsection*{Was ist Echtzeit?} Vor der Betrachtung verschiedener Ansätze, Linux echtzeitfähig zu machen, ist es -notwendig einige grundlegende Begrifflichkeiten zur erläutern: +notwendig, einige grundlegende Begrifflichkeiten zur erläutern: \begin{itemize} \item Echtzeit: Zur Definition eines Echtzeitsystems kann man folgende Aussagen Treffen: Auf -einem Echtzeitsystem hängt die Korrektheit einer Berechnung nicht nur von deren +einem Echtzeitsystem hängt die Korrektheit einer Berechnung nicht nur von ihrer logischen Korrektheit, sondern auch von der Ausführung zum korrekten Zeitpunkt ab. Das Nichteinhalten eines bestimmten Zeitrahmens resultiert in einem Fehler. \item Latenzzeit: Unter Latenzzeit versteht man den Zeitraum zwischen dem @@ -47,7 +47,7 @@ Gelöst werden kann dieses Problem durch ''prioriy inheritance'' und ''priority \begin{itemize} \item Prioritätsvererbung / priority inheritance: Hier wird die Priorität der niederprioren Task angehoben, um zu erreichen, daß die blockierte Resource -freigegeben kann. +freigegeben werden kann. \item Prioritätsgrenzen / priority ceiling: Hier wird für jede Resource eine Prioritätsgrenze festgelegt. Jede Task, die die Resource belegt, wird auf die Prioritätsgrenze der Resource angehoben. @@ -94,7 +94,7 @@ RTAI ist ein typischer Vertreter des Dual Kernel Ansatzes. Abbildung Das Xenomai Projekt wurde im Jahre 2001 gegründet. Im Gegensatz zu RTAI erlaubt Xenomai auch Echtzeit im Userpace (RTAI erlaubt dies nur sehr eingeschränkt). Die Besonderheit von Xenomai sind die sogenannten Skins, die es vereinfachen sollen, -Applikationen von proprietären Echtzeitsystemen nach Xenomai zu portieren. +Applikationen von anderen Echtzeitsystemen nach Xenomai zu portieren. Xenomai Skins bilden die API dieser Systeme ab. Xenomai unterstützt derzeit folgende Architekturen: PowerPC32, PowerPC64, x86, x86\_64, Blackfin, ARM und ia64). Die zentralen Begriffe im Designkonzept von Xenomai stellen Xenomai @@ -104,9 +104,9 @@ IPIPE kann bildlich als virtueller Interruptkontroller betrachtet werden. Sie organisiert das System in verschiedenen Domains. Interrupts werden von IPIPE entgegengenommen und an die einzelnen Domains verteilt. Nucleus beeinhaltet die Xenomai Core Funktionalität. Dieser ist zuständig dafür, -alle notwendigen Resourcen, die Skins benötigen, um die Funktionalität von -RTOSsen nachzubilden. Der Hardware Abstraction Layer beinhaltet den Plattform -und CPU abhängigen Code. Alle darüberliegenden Layer (darunter auch Nucleus) +alle notwendigen Resourcen bereitzustellen, die Skins benötigen, um die Funktionalität +von RTOSsen nachbilden zu können. Der Hardware Abstraction Layer beinhaltet +den Plattform und CPU abhängigen Code. Alle darüberliegenden Layer (darunter auch Nucleus) bauen darauf auf. HAL ist kombiniert mit dem System Abstraction Layer. Dieser soll die darüberliegenden Layer, wie z.B. Nucleus, noch portierbarer machen. Abbildung \ref{img:xenomai} zeigt das technische Zusammenspiel der Xenomai @@ -143,7 +143,7 @@ generisches Interrupthandling für alle Architekturen und mit 2.6.30 nun auch di Threaded Interrupt Handler. Weiterhin hat sich die Linux Entwicklergemeinde bereits 2006 darauf geeinigt, daß Preempt RT in den Linux Kernel integriert wird. Weiterhin bietet der -Realtime Preempton Patch den großen Vorteil, daß Echtzeitapplikationen als POSIX +Realtime Preemption Patch den großen Vorteil, daß Echtzeitapplikationen als POSIX Realtime Applikationen geschrieben werden. Es wird keine spezielle API verwendet. Preempt RT Unterstützt eine Vielzahl von Architekturen (PowerPc, x86, x86\_64, MIPS, ARM, ...). @@ -154,7 +154,7 @@ x86\_64, MIPS, ARM, ...). \label{img:preempt_rt} \end{figure} Wie Abbildung \ref{img:preempt_rt} zeigt, integriert Preempt RT die -Echtzeitfunktionalität ''natlos'' in den Linux Kernel. Auch die Entwickler +Echtzeitfunktionalität ''nahtlos'' in den Linux Kernel. Auch die Entwickler anderer Projekte haben die Vorzüge von Preempt RT bereits erkannt. Die Roadmap für Xenomai 3 sieht Preempt RT Support vor. Dies würde den Einsatz von Xenomai Skins auf Preempt RT Kerneln ermgöglichen. @@ -164,7 +164,7 @@ Skins auf Preempt RT Kerneln ermgöglichen. \begin{enumerate} \item Was sind die wichtigsten Anforderungen an ein Echtzeitsystem? \item Welche beiden Ansätze gibt es, um Linux echtzeitfähig zu machen? -\item Was sind die bekanntesten Vertreter für Echtzeitlinux und welchen der oben +\item Was sind die bekanntesten Vertreter für Echtzeitlinux und welche der oben beschriebenen Ansätze verfolgen Sie? \item Wird für das Schreiben einer Echtzeitapplikation mit Preempt RT eine spezielle API benötigt? diff --git a/realtime/rt-basics/pres_rt-basics_de.tex b/realtime/rt-basics/pres_rt-basics_de.tex index c60f8a5..128b115 100644 --- a/realtime/rt-basics/pres_rt-basics_de.tex +++ b/realtime/rt-basics/pres_rt-basics_de.tex @@ -181,7 +181,7 @@ Nicht Einhalten des korrekten Zeitrahmens führt zu einem Fehler! \begin{frame} \frametitle{Preempt RT und Mainline} \textit{''Controlling a laser with Linux is crazy, but everyone in this room is -crazy in his own way. So if you want to use Linux to control an an industrial +crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using Preempt RT''} - Linus Torvalds auf dem Kernel Summit 2006 \end{frame} -- cgit v1.2.3 From a3dd8a86b6e4c60630141721c7f4cb4adb73b043 Mon Sep 17 00:00:00 2001 From: Jan Altenberg Date: Sat, 20 Jun 2009 12:39:37 +0200 Subject: RT speciality fixes --- .../rt-specialties/handout_rt-specialties_de.tex | 41 ++++++++++++---------- realtime/rt-specialties/pres_rt-specialties_de.tex | 4 +-- 2 files changed, 25 insertions(+), 20 deletions(-) diff --git a/realtime/rt-specialties/handout_rt-specialties_de.tex b/realtime/rt-specialties/handout_rt-specialties_de.tex index 372aa25..33dc9b6 100644 --- a/realtime/rt-specialties/handout_rt-specialties_de.tex +++ b/realtime/rt-specialties/handout_rt-specialties_de.tex @@ -89,7 +89,7 @@ Die RT Tests sind eine Sammlung von Programmen, zur Validierung der Eigenschaften von Echtzeitsystemen. Die RT Tests umfassen folgende Tools: \begin{itemize} \item cyclictest: High Resolution Timer Testsoftware. -\item hwlatdetect: Python Script, zur Steuerung des Kernelmoduls zur Erkennung +\item hwlatdetect: Python Script zur Steuerung des Kernelmoduls zur Erkennung von System Management Interrupts (hwlat\_detector). \item pi\_stress: Stresstest für Mutexe mit Priority Inheritance Attribut \item signaltest: Benchmark, bei dem Signale zwischen Tasks ausgetauscht werden. @@ -108,10 +108,10 @@ make Cyclictest ist die wohl meistgenutzte Testsoftware auf Preempt RT Systemen. Mit Cyclictest kann eine bestimmte Anzahl von Timertasks mit einem definierten Interval aufgesetzt werden. Für diese Tasks wird kontinuierlich die Abweichung -zum gewünschten Interval gemessen und hierfür die Maximale und Durchschnittliche +zum gewünschten Intervall gemessen und hierfür die Maximale und Durchschnittliche Abweichung aufgezeichnet. Die wichtigsten Parameter für Cyclictest sind die Anzahl und die Priorität der gewünschten Timertasks, die Art des zu verwendenden -Timers und das gewünschte Timerinterval: +Timers und das gewünschte Timerintervall: \begin{lstlisting} # 4 Timertasks (2000 , 2500, 3000, 3500us) # -i options tells us the interval of the first task @@ -130,7 +130,7 @@ T: 3 ( 2124) P:77 I:3500 C: 723 Min: 67 Act: 95 Avg: 96 Max: 177 \end{lstlisting} \subsection*{Lastszenarien} Um eine Aussage über das Echtzeitverhaltens treffen zu können, interessiert in -der Hauptsache das Verhalten in Worst-Case Szenarien (hohe CPU Laste, hohe +der Hauptsache das Verhalten in Worst-Case Szenarien (hohe CPU Last, hohe Interruptlast). Ein ausgezeichnetes Werkzeug, um CPU Last zu erzeugen, ist ''hackbench''. Hackbench wurde ursprünglich als Schedulerbenchmark entwickelt. Es erzeugt eine bestimme Anzahl an Prozessgruppen von Clients und Servern, die @@ -154,9 +154,15 @@ aushungerte. Daher wurde eine Option eingeführt, die die Laufzeit von Realtime Tasks beschränken kann. Überschreiten die Realtime Tasks dieses Zeitlimit, werden diese für einen bestimmten Zeitraum nicht mehr geschedult. Die Standardeinstellung liegt bei 950ms. Bei Überschreiten der 950ms werden die -Echtzeittasks für 50ms suspendiert. Dieser Wert kann durch Schreiben des -gewünschten Wertes nach /proc/sys/kernel/sched\_rt\_runtime\_us angepaßt werden. -Zum Deaktivieren dieser Funktion muß folgendes getan werden: +Echtzeittasks für 50ms suspendiert. +Da Interrupts unter Preempt RT als Kernelthread mit Echtzeitprioriät laufen +und durch den Floodping eine hohe Anzahl an Netzwerkinterrupts +(einschliesslich der zugehörigen Softinterrupts) erzeugt wird, nehmen Realtime +Tasks im System einen Großteil der Resourcen ein. Somit kann es passieren, daß +dieses Zeitlimit überschritten wird. +Das Limit für die Rechenzeit kann durch Schreiben des gewünschten Wertes nach +/proc/sys/kernel/sched\_rt\_runtime\_us angepaßt werden. +Zum Deaktivieren dieser Funktion muß Folgendes getan werden: \begin{lstlisting} echo -1 > /proc/sys/kernel/sched_rt_runtime_us \end{lstlisting} @@ -225,13 +231,13 @@ Die oben aufgelistete Applikation zeigt sehr schön, was notwendig ist, um eine Applikation mit deterministischem Zeitverhalten zu erzeugen: \begin{itemize} \item RT Scheduling Policy und Priorität festlegen -\item Speicher locken, um zu vermeiden, um undeterministisches Zeitverhalten -durch Pagefaults auszuschliessen. -\item ''Stack Pre-Faulting'', um zu zu vermeiden, daß Stackfaults +\item Speicher locken, um undeterministisches Zeitverhalten durch +Pagefaults auszuschliessen. +\item ''Stack Pre-Faulting'', um zu vermeiden, daß Stackfaults undeterministisches Zeitverhalten verursachen \end{itemize} -Eine Ausgezeichnete Einführung zum Erstellen von Echtzeitapplikation und zur -Verwendung von Preempt RT, findet sich unter:\newline +Eine Ausgezeichnete Einführung zum Erstellen von Echtzeitapplikationen und zur +Verwendung von Preempt RT findet sich unter:\newline http://rt.wiki.kernel.org \subsection*{Tracing / Latenzen aufspüren} \subsubsection*{FTrace} @@ -239,18 +245,17 @@ Ein hervorragendes Werkzeug, um kernelseitige Codepfade aufzuspüren, die lange Latenzzeiten verursachen, ist Ftrace. Ftrace wird über DebugFS, einem virtuellen Dateisystem, gesteuert und platziert dort auch seine Ausgaben. Die einfachste Methode, FTrace zu verwenden ist Cyclictest. Cyclictest biete bereits einige -Optionen, um FTrace zu verwenden. Die Option -f schällt Cyclictests Ftrace +Optionen, um FTrace zu steuern. Die Option -f schällt Cyclictests Ftrace Support an, -b veranlaßt Cyclictest, bei Überschreiten einer maximalen Latenzzeit, abzubrechen und einen Trace zu triggern. \subsubsection*{Kerneloptionen für FTrace} -Um FTrace verwenden zu können, müssen beim Konfigurieren des Kernel einige +Um FTrace verwenden zu können, müssen beim Konfigurieren des Kernels einige unter dem Menupunkt ''Kernel hacking-->Tracers'' einige Optionen aktiviert werden: \begin{itemize} \item Kernel Function Tracer -\item Optional: Beliebige Optionen, die mit Trace beginnen (der zu verwendende +\item Beliebige Optionen, die mit Trace beginnen (der zu verwendende Tracetyp kann cyclictest über die Commandline mitgegeben werden, siehe -cyclictest -h. Default ist der -Event Tracer) +cyclictest -h. Default ist der Event Tracer) \end{itemize} \subsubsection*{Beispiel eines Traces} Das Erstellen eines Traces mit cyclictest läßt sich am Besten mit einem Beispiel @@ -293,7 +298,7 @@ IRQ-129-772 [000] 4154503386.851234: timer_interrupt<-ret_from mindestens gesetzt sein? \item Wozu dient das Tool cyclictest? \item Welchen bekannten ''Pitfall'' gibt es bzgl. hoher Latencies mit Floodping -als Lastszenario? Wie kann dieser behoben werden? +als Lastszenario? Wie kann dieser umgangen werden? \item Welche 3 Schritte sind notwendig, um das deterministische Zeitverhalten einer Applikation zu garantieren? \end{itemize} diff --git a/realtime/rt-specialties/pres_rt-specialties_de.tex b/realtime/rt-specialties/pres_rt-specialties_de.tex index e7e3d1d..046521d 100644 --- a/realtime/rt-specialties/pres_rt-specialties_de.tex +++ b/realtime/rt-specialties/pres_rt-specialties_de.tex @@ -107,14 +107,14 @@ RT Tests: \item Setzt beliebige Anzahl von Realtime Tasks mit unterschiedlicher Priorität und unterschiedlichen Intervallen auf \item Viele Debuggingmöglichkeiten -\item Sehr Aussagekräftig, um echtzeitverhalten auf einer bestimmten Plattform +\item Sehr Aussagekräftig, um Echtzeitverhalten auf einer bestimmten Plattform zu beurteilen. \end{itemize} \end{frame} \begin{frame} \frametitle{Lastszenarien} -Geeignete Lastszenarien, um Worst-Case Situationen nachstellen /provozieren zu +Geeignete Lastszenarien, um Worst-Case Situationen nachstellen / provozieren zu können: \begin{itemize} \item CPU Last: ''hackbench'', ursprünglich als Scheduler Benchmark geschrieben. -- cgit v1.2.3 From a551970fa4444d11ad2ac27da031eac82f8f7f08 Mon Sep 17 00:00:00 2001 From: "Hans J. Koch" Date: Sat, 20 Jun 2009 16:11:26 +0200 Subject: Made the default make target --- Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile b/Makefile index 494db82..36e06c2 100644 --- a/Makefile +++ b/Makefile @@ -1,5 +1,8 @@ SUBDIRS = kernel-devel linux-basics realtime application-devel +default: + make all + latex-install: mkdir -p /usr/share/texmf-texlive/tex/latex/linutronix cp latex/lxarticle/lxarticle.cls /usr/share/texmf-texlive/tex/latex/linutronix/ -- cgit v1.2.3 From 35ffd5faef3568576caba892277f186487ba01c7 Mon Sep 17 00:00:00 2001 From: Jan Altenberg Date: Sun, 21 Jun 2009 16:21:44 +0200 Subject: Added Makefile for embedded-devel --- application-devel/embedded-devel/Makefile | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 application-devel/embedded-devel/Makefile diff --git a/application-devel/embedded-devel/Makefile b/application-devel/embedded-devel/Makefile new file mode 100644 index 0000000..22cf5f3 --- /dev/null +++ b/application-devel/embedded-devel/Makefile @@ -0,0 +1,8 @@ +all: + pdflatex handout_embedded-devel_de.tex + pdflatex pres_embedded-devel_de.tex + pdflatex hints_embedded-devel_de.tex + +clean: + rm -f *.aux *.log *.pdf *.log *.snm *.toc *.vrb *.nav *.out + -- cgit v1.2.3 From 9c7729b91797c028d90462529d81856ecf8a43f9 Mon Sep 17 00:00:00 2001 From: "Hans J. Koch" Date: Sun, 21 Jun 2009 17:04:17 +0200 Subject: Added kernel-devel/kernel-build --- kernel-devel/kernel-build/Makefile | 9 + .../kernel-build/handout_kernel-build_de.tex | 225 ++++++++++++++++++++- kernel-devel/kernel-build/images/menu_rt_001.png | Bin 0 -> 30735 bytes kernel-devel/kernel-build/pres_kernel-build_de.tex | 27 ++- 4 files changed, 241 insertions(+), 20 deletions(-) create mode 100644 kernel-devel/kernel-build/Makefile create mode 100644 kernel-devel/kernel-build/images/menu_rt_001.png 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//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 Binary files /dev/null and b/kernel-devel/kernel-build/images/menu_rt_001.png differ 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} -- cgit v1.2.3 From afd08dc5de43af71d11f41c3d9d84a695d15efd5 Mon Sep 17 00:00:00 2001 From: "Hans J. Koch" Date: Sun, 21 Jun 2009 17:05:15 +0200 Subject: Update handout sh-programming --- .../sh-programming/handout_sh-programming_de.tex | 190 ++++++++++++++++++++- 1 file changed, 188 insertions(+), 2 deletions(-) diff --git a/linux-basics/sh-programming/handout_sh-programming_de.tex b/linux-basics/sh-programming/handout_sh-programming_de.tex index 5590e6e..f27f70e 100644 --- a/linux-basics/sh-programming/handout_sh-programming_de.tex +++ b/linux-basics/sh-programming/handout_sh-programming_de.tex @@ -10,17 +10,203 @@ \subsection*{Aufbau von Shell-Skripten} -Text +\begin{itemize} +\item Syntax: \cmd{\#!/ein/interpreter} +\item Beliebiges Programm als Interpreter möglich +\item Beispiele hier: \cmd{\#!/bin/sh} +\item Danach beliebige Shell-Befehle möglich +\end{itemize} + +Das übliche \cmd{Hello World} sieht als Shell-Skript etwa so aus: + +\begin{lstlisting} +#!/bin/sh +echo Hello World +\end{lstlisting} \subsection*{Variablen und Parameter} -Text +\begin{lstlisting} +#!/bin/sh + +MY_VAR=17 +PAR_1=$1 +datum=`date` + +echo variable is $(MYVAR), parameter is $(PAR_1) +\end{lstlisting} + +Variablen können einfach in der Form \cmd{Name=Wert} geschrieben werden. Sie +haben in Shell-Skripten keinen Typ und werden bei der ersten Verwendung +automatisch angelegt. + +\subsection*{Ausgabe-Umleitung} + +\begin{lstlisting} +#!/bin/sh + +# How many lines in addr.txt contain "Jones" ? +# Store the result in "jones_count" +grep Jones addr.txt | wc -l > jones_count + +# Append a message to a log file +echo "My message" >> log_file + +exit 0 +\end{lstlisting} + \subsection*{Bedingte Verzweigungen} +Allgemeine Form: + +\begin{lstlisting} +#!/bin/sh + +if [ bedingung ] + then + ... + else + ... +fi + +# in one line: + +if [ bedingung ] ; then ... ; fi +\end{lstlisting} + +Zahlentests: + +\begin{lstlisting} +#!/bin/sh + +# Zahlentests: -eq -ne -lt -gt -le -ge +zahl=15 +if [ $zahl -lt 20 ] ; then ... + +# String-Tests: = != < > -n -z +string="Hallo" +if [ $string != "hello" ] ; then ... +\end{lstlisting} + +Dateitests: + +\begin{lstlisting} +#!/bin/sh +# Dateitests, z.B. if [ -f $datei ] ; then ... +# Auswahl: +# -f ist eine normale Datei +# -d ist ein Verzeichnis +# -e existiert +# -s existiert und ist nicht leer +# -r ist lesbar +# -w ist schreibbar +# -x ist ausfuehrbar +# -b ist ein Block Device +# -c ist ein Character Device +\end{lstlisting} + +Test des Rückgabewerts von Programmen: + +\begin{lstlisting} +#!/bin/sh + +# Does addr.txt contain "Jones" ? +if grep Jones addr.txt ; then ... + +# Return value 0 means OK +exit 0 + +\end{lstlisting} + +Short circuit tests: + +\begin{lstlisting} +#!/bin/sh + +# Short circuit tests: + +make && make install + +grep Jones addr.txt || echo "No Jones found!" +\end{lstlisting} + \subsection*{Schleifen} + +For-Schleife: + +\begin{lstlisting} +#!/bin/sh + +for datei in datei1 datei2 datei3 +do + cp $datei $datei.bak +done + +for datei in * +do + ... +done +\end{lstlisting} + +While-Schleife: + +\begin{lstlisting} +#!/bin/sh + +while [ bedingung ] +do + ... +done + +while [ bedingung ] ; do ... ; done + +# bedingung wie bei if +\end{lstlisting} + +\subsection*{Funktionen} + +\begin{lstlisting} +#!/bin/sh + +error_log() { + echo "Fehler: $1" >> my_log_file +} + +... + +error_log "Datei nicht gefunden." +\end{lstlisting} + \subsection*{Einbinden anderer Skripte} + +\begin{lstlisting} +#!/bin/sh + +# Include an external script: +. my_other_script + +# run another script/command in the background: +my_other_script& + +\end{lstlisting} + \subsection*{Zugriff auf Dateien} +\begin{lstlisting} +#!/bin/sh + +ls -1 > dateiliste.txt + +while read dateiname +do + if [ -d $dateiname ] + then + echo "$dateiname ist ein Verzeichnis" + fi +done < dateiliste.txt + +\end{lstlisting} + \end{document} -- cgit v1.2.3 From f45f06860f0e60acd5ce3297581288f9b13f884a Mon Sep 17 00:00:00 2001 From: Jan Altenberg Date: Mon, 22 Jun 2009 00:35:17 +0200 Subject: Added Linus' newsgroup message to the 'What is Linux?' part --- linux-basics/what-is-linux/pres_what-is-linux_de.tex | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/linux-basics/what-is-linux/pres_what-is-linux_de.tex b/linux-basics/what-is-linux/pres_what-is-linux_de.tex index 85bcdb2..fbd44f1 100644 --- a/linux-basics/what-is-linux/pres_what-is-linux_de.tex +++ b/linux-basics/what-is-linux/pres_what-is-linux_de.tex @@ -45,6 +45,19 @@ \end{figure} \end{frame} +% ----- Slide ------------------ +\begin{frame}[fragile] +\begin{verbatim} +Hello everybody out there using minix - + +I'm doing a (free) operating system (just a hobby, +won't be big andprofessional like gnu) for +386(486) AT clones. This has been brewing +since april, and is starting to get ready. +\end{verbatim} +Linus Torvalds (1991 / Minix newsgroup) +\end{frame} + % ----- Slide ------------------ \begin{frame} \begin{figure}[h] -- cgit v1.2.3 From 719085c3dc98ab3df272476e16e983e4a16fe14b Mon Sep 17 00:00:00 2001 From: "Hans J. Koch" Date: Mon, 22 Jun 2009 01:24:09 +0200 Subject: Added kernel-devel/uio-driver/ presentation (English version) --- kernel-devel/uio-driver/Makefile | 10 + .../uio-driver/images/greg-all-hardware.jpg | Bin 0 -> 76025 bytes kernel-devel/uio-driver/images/greg-kernel-org.jpg | Bin 0 -> 75068 bytes kernel-devel/uio-driver/images/hjk-desperate.jpg | Bin 0 -> 122993 bytes kernel-devel/uio-driver/images/ioctl-vs-uio.png | Bin 0 -> 106503 bytes .../uio-driver/images/konventioneller-treiber.png | Bin 0 -> 104184 bytes kernel-devel/uio-driver/images/uio-treiber.png | Bin 0 -> 126807 bytes kernel-devel/uio-driver/pres_uio-driver_en.tex | 302 +++++++++++++++++++++ 8 files changed, 312 insertions(+) create mode 100644 kernel-devel/uio-driver/Makefile create mode 100644 kernel-devel/uio-driver/images/greg-all-hardware.jpg create mode 100644 kernel-devel/uio-driver/images/greg-kernel-org.jpg create mode 100644 kernel-devel/uio-driver/images/hjk-desperate.jpg create mode 100644 kernel-devel/uio-driver/images/ioctl-vs-uio.png create mode 100644 kernel-devel/uio-driver/images/konventioneller-treiber.png create mode 100644 kernel-devel/uio-driver/images/uio-treiber.png create mode 100644 kernel-devel/uio-driver/pres_uio-driver_en.tex 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 Binary files /dev/null and b/kernel-devel/uio-driver/images/greg-all-hardware.jpg differ 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 Binary files /dev/null and b/kernel-devel/uio-driver/images/greg-kernel-org.jpg differ 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 Binary files /dev/null and b/kernel-devel/uio-driver/images/hjk-desperate.jpg differ 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 Binary files /dev/null and b/kernel-devel/uio-driver/images/ioctl-vs-uio.png differ 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 Binary files /dev/null and b/kernel-devel/uio-driver/images/konventioneller-treiber.png differ 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 Binary files /dev/null and b/kernel-devel/uio-driver/images/uio-treiber.png differ 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} -- cgit v1.2.3