Introduced the first draft of some new topics.

_BASIC_ introduction to:

* Open Source licenses
* Scheduling / Process Management
* UDEV

1 files changed, 224 insertions, 0 deletions

diff --git a/linux-basics/linux-processes/pres_linux-processes_en.tex b/linux-basics/linux-processes/pres_linux-processes_en.tex
new file mode 100644
index 0000000..73582d8
--- /dev/null
+++ b/linux-basics/linux-processes/pres_linux-processes_en.tex
@@ -0,0 +1,224 @@
+\documentclass[11pt]{beamer}
+
+%\usepackage{ngerman}
+\usepackage{times}
+\usepackage{graphicx}
+\usepackage{pgf,pgfarrows,pgfnodes,pgfautomata,pgfheaps}
+\usepackage{amsmath,amssymb}
+\usepackage[latin1]{inputenc}
+\usepackage{listings,color}
+\definecolor{lbcolor}{RGB}{255,210,150}
+\lstset{
+	language=C,
+	numbers=left,
+	stepnumber=1,
+	numbersep=5pt,
+	numberstyle=\tiny,
+	breaklines=true,
+	breakautoindent=true,
+	postbreak=\space,
+	tabsize=2,
+	basicstyle=\ttfamily\footnotesize,
+	showspaces=false,
+	showstringspaces=false,
+	extendedchars=true,
+	backgroundcolor=\color{lbcolor},
+	keywordstyle=\bf ,
+	commentstyle=\color{green},
+	stringstyle=\color{red}
+}
+
+\mode<presentation>
+{
+	\usetheme{linutronix}
+}
+
+% on the following slides, include icon in the left sidebar
+\def\lximg{/usr/share/lx/icons/fueller.png}
+
+\title{Linux process mangagement / Scheduling / Daemons}
+\institute{Linutronix GmbH}
+
+\begin{document}
+
+\frame{ \titlepage }
+
+% stop displaying 'fueller.png' on the following slides
+\def\lximg{none}
+
+\section{Process Management}
+\begin{frame}
+\frametitle{Process creation}
+From the operatings system's point of view, there are basically two steps,
+which are performed when starting a process.
+\begin{itemize}
+\item A process is created using the fork() system call
+\item The execve() system call loads a new program into the process memory
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Parent / Child}
+\begin{itemize}
+\item init is the first process, which is started (PID == 1), so
+\item init is the parent of all processes on the system
+\item A parent waits for its childs termination using the wait() system call
+\item If the parent process terminates, before the child terminates, the child
+is ''adopted'' by PID 1
+\item A child which terminates before its parent was able to do a wait() is
+turned into a ''Zombie''
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Task states}
+Each task can have one of the following states:
+\begin{itemize}
+\item Interruptible sleep (waiting for an event) (S)
+\item Uninterruptible sleep (waiting for I/O) (D)
+\item Running (R)
+\item Stopped (T)
+\item Defunct / ''Zombie'' (Z)
+\end{itemize}
+\end{frame}
+
+\begin{frame}[fragile]
+\frametitle{Task states}
+''ps aux'' also shows the task state:
+\begin{verbatim}
+USER       PID         STAT       COMMAND
+postfix   5034  [...]   S    [...] pickup -l
+jan       5303  [...]   SN+  [...] man 8 init
+jan       5313  [...]   SN+  [...] pager -s
+jan       5390  [...]   SNl  [...] evince
+jan       5416  [...]   SNs  [...] bash
+\end{verbatim}
+The first column in the STAT field shows the process state.
+\end{frame}
+
+\section{Scheduling}
+\begin{frame}
+\frametitle{The LINUX Scheduler}
+\begin{itemize}
+\item Responsiveness
+\item Fairness
+\item Throughput
+\item O(log n)
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Scheduling classes}
+Normal processes:
+\begin{itemize}
+\item SCHED\_OTHER
+\item SCHED\_BATCH (Linux specific; since 2.6.16)
+\item SCHED\_IDLE (Linux specific; since 2.6.23)
+\end{itemize}
+Realtime:
+\begin{itemize}
+\item SCHED\_FIFO
+\item SCHED\_RR
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{The nice value}
+\begin{itemize}
+\item Non-Realtime processes don't have a static priority!
+\item Their priority is calculated dynamically
+\item The calculation can be influenced by the ''nice value''
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{The nice value}
+\begin{itemize}
+\item The range for possible nice values is: -20 .. +19
+\item It tells the system how ''NICE'' the process should behave towards other
+processes. So, -20 means ''high priority'' and +19 ''low priority''
+\end{itemize}
+\end{frame}
+
+\begin{frame}[fragile]
+\frametitle{The nice value}
+The nice value can be changed using the ''nice'' and the ''renice'' command:
+\begin{verbatim}
+Usage: nice [OPTION] [COMMAND [ARG]...]
+-n, --adjustment=N
+
+renice [-n] prio [-p|--pid] pid  [.. pid]
+renice [-n] prio  -g|--pgrp pgrp [.. pgrp]
+renice [-n] prio  -u|--user user [.. user]
+\end{verbatim}
+\end{frame}
+
+\begin{frame}
+\frametitle{SCHED\_IDLE and SCHED\_BATCH}
+\begin{itemize}
+\item SCHED\_BATCH: The scheduler will always assume the process to be CPU
+intensive and therefor will apply a penalty when calculating the dynamic
+priority.
+\item SCHED\_IDLE: For very low prio processes. Even the nice value is
+ignored. The resulting priority will be \textbf{below} SCHED\_OTHER and SCHED\_BATCH
+with nice +19 assigned to it!
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Realtime scheduling classes}
+\begin{itemize}
+\item SCHED\_FIFO: Static priority
+\item SCHED\_RR: Priority based, Round Robin scheduling per priority
+\end{itemize}
+Both Realtime scheduling classes accept priorities from 1 to 99, where 99 is
+the highest priority.
+\end{frame}
+
+\begin{frame}[fragile]
+\frametitle{Setting the Scheduling class}
+The scheduling class can be set using the chrt command:
+\begin{verbatim}
+Set policy:
+  chrt [opts] <policy> <prio> <pid>
+  chrt [opts] <policy> <prio> <cmd> [<arg> ...]
+Get policy:
+  chrt [opts] {<pid> | <cmd> [<arg> ...]}
+Scheduling policies:
+-b | --batch set policy to SCHED_BATCH
+-f | --fifo  set policy to SCHED_FIFO
+-i | --idle  set policy to SCHED_IDLE
+-o | --other set policy to SCHED_OTHER
+-r | --rr    set policy to SCHED_RR (default)
+\end{verbatim}
+\end{frame}
+
+\section{Daemons}
+\begin{frame}
+\frametitle{Daemons}
+\begin{alertblock}{What is a Daemon?}
+A Daemon runs in background and is not attached to a terminal. Daemons are
+used for specific tasks, such as a web-server, a printer server, ...
+\end{alertblock}
+\end{frame}
+
+\begin{frame}
+\frametitle{How a Daemon gets created}
+\begin{itemize}
+\item Like any other process, a Daemon is created using fork()
+\item after forking the parent exits, which causes the child to be ''adopted''
+by PID 1
+\item then the child calls setsid(), to create a new session for that process
+\item afterwards several administrative tasks will be done (like changing the
+working directory and so on...)
+\end{itemize}
+\end{frame}
+
+\section*{sources}
+\begin{frame}
+\begin{thebibliography}{1}
+\bibitem{kerisk10} The Linux Programming Interface (Michael Kerisk), no starch
+press, ISBN 978-1-59327-220-3
+\end{thebibliography} 
+\end{frame}
+\end{document}