[FE training-materials-updates] Cosmetic or minor improvements
Michael Opdenacker
michael.opdenacker at free-electrons.com
Tue Oct 16 09:48:31 CEST 2012
Repository : git://git.free-electrons.com/training-materials.git
On branch : master
Link : http://git.free-electrons.com/training-materials/commit/?id=30cf38b0571fe97e9c1b6c67e879cad07f961cb2
>---------------------------------------------------------------
commit 30cf38b0571fe97e9c1b6c67e879cad07f961cb2
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date: Thu Oct 11 21:19:15 2012 +0200
Cosmetic or minor improvements
>---------------------------------------------------------------
30cf38b0571fe97e9c1b6c67e879cad07f961cb2
.../android-native-layer-init.tex | 2 +-
...nel-driver-development-architecture-drivers.tex | 19 +++++------
.../kernel-driver-development-concurrency.tex | 8 ++---
.../sysdev-embedded-linux.tex | 14 ++++-----
.../sysdev-root-filesystem-virtual-fs.tex | 3 +-
slides/sysdev-udev/sysdev-udev.tex | 33 ++++++++++----------
6 files changed, 40 insertions(+), 39 deletions(-)
diff --git a/slides/android-native-layer-init/android-native-layer-init.tex b/slides/android-native-layer-init/android-native-layer-init.tex
index 1c237d7..ca985d8 100644
--- a/slides/android-native-layer-init/android-native-layer-init.tex
+++ b/slides/android-native-layer-init/android-native-layer-init.tex
@@ -184,7 +184,7 @@ service akmd /sbin/akmd
\frametitle{Uevent}
\begin{itemize}
\item Init also manages the runtime events generated by the kernel
- when hardware is plugged in or removed, like udev does on a standard
+ when hardware is plugged in or removed, like \code{udev} does on a standard
Linux distribution
\item This way, it dynamically creates the devices nodes under \code{/dev}
\item You can also tweak its behavior to add specific permissions to
diff --git a/slides/kernel-driver-development-architecture-drivers/kernel-driver-development-architecture-drivers.tex b/slides/kernel-driver-development-architecture-drivers/kernel-driver-development-architecture-drivers.tex
index 5af919a..dd9d790 100644
--- a/slides/kernel-driver-development-architecture-drivers/kernel-driver-development-architecture-drivers.tex
+++ b/slides/kernel-driver-development-architecture-drivers/kernel-driver-development-architecture-drivers.tex
@@ -168,7 +168,7 @@ static int __devinit xxxfb_probe (struct pci_dev *dev,
\item Minimization of code duplication
\item Common facilities (reference counting, event notification,
power management, etc.)
- \item Enumerate the devices view their interconnections, link the
+ \item Enumerate the devices, view their interconnections, link the
devices to their buses and drivers, etc.
\end{itemize}
\item Understanding the device model is necessary to understand how
@@ -259,7 +259,7 @@ static int __devinit xxxfb_probe (struct pci_dev *dev,
\item The \code{MODULE_DEVICE_TABLE} macro allows \code{depmod} to
extract at compile time the relation between device identifiers
and drivers, so that drivers can be loaded automatically by
- udev. See \code{/lib/modules/$(uname -r)/modules.{alias,usbmap}}
+ \code{udev}. See \code{/lib/modules/$(uname -r)/modules.{alias,usbmap}}
\end{itemize}
\begin{minted}[fontsize=\footnotesize]{c}
static struct usb_device_id rtl8150_table[] = {
@@ -281,7 +281,7 @@ MODULE_DEVICE_TABLE(usb, rtl8150_table);
\item \code{struct usb_driver} is a structure defined by the USB
core. Each USB device driver must instantiate it, and register
itself to the USB core using this structure
- \item This structure inherits from struct driver, which is defined
+ \item This structure inherits from \code{struct driver}, which is defined
by the device model.
\begin{minted}{c}
static struct usb_driver rtl8150_driver = {
@@ -325,12 +325,12 @@ module_exit(usb_rtl8150_exit);
\begin{itemize}
\item The USB adapter driver that corresponds to the USB controller
of the system registers itself to the USB core
- \item The rtl8150 USB device driver registers itself to the USB core
+ \item The \code{rtl8150} USB device driver registers itself to the USB core
\begin{center}
\includegraphics[height=0.4\textheight]{slides/kernel-driver-development-architecture-drivers/usb-registering.pdf}
\end{center}
\item The USB core now knows the association between the
- vendor/product IDs of rtl8150 and the \code{usb_driver} structure
+ vendor/product IDs of \code{rtl8150} and the \code{usb_driver} structure
of this driver
\end{itemize}
\end{frame}
@@ -401,14 +401,15 @@ static int rtl8150_probe(struct usb_interface *intf,
kernel
\item The \code{sysfs} virtual filesystem offers a mechanism to
export such information to userspace
- \item Used for example by udev to provide automatic module loading,
+ \item Used for example by \code{udev} to provide automatic module loading,
firmware loading, device file creation, etc.
\item \code{sysfs} is usually mounted in \code{/sys}
\begin{itemize}
\item \code{/sys/bus/} contains the list of buses
\item \code{/sys/devices/} contains the list of devices
- \item \code{/sys/class} enumerates devices by class (net, input,
- block...), whatever the bus they are connected to. Very useful!
+ \item \code{/sys/class} enumerates devices by class (\code{net},
+ \code{input}, \code{block}...), whatever the bus they are connected
+ to. Very useful!
\end{itemize}
\item Take your time to explore \code{/sys} on your workstation.
\end{itemize}
@@ -566,7 +567,7 @@ sport->rxirq = platform_get_irq(pdev, 0);
\item In addition to the well-defined resources, many drivers
require driver-specific information for each platform device
\item Such information can be passed using the \code{platform_data}
- field of the struct device (from which
+ field of \code{struct device} (from which
\code{struct platform_device} inherits)
\item As it is a \code{void *} pointer, it can be used to pass any
type of information.
diff --git a/slides/kernel-driver-development-concurrency/kernel-driver-development-concurrency.tex b/slides/kernel-driver-development-concurrency/kernel-driver-development-concurrency.tex
index 138955b..ea10f99 100644
--- a/slides/kernel-driver-development-concurrency/kernel-driver-development-concurrency.tex
+++ b/slides/kernel-driver-development-concurrency/kernel-driver-development-concurrency.tex
@@ -4,7 +4,7 @@
\frametitle{Sources of concurrency issues}
\begin{itemize}
\item In terms of concurrency, the kernel has the same constraint
- has a multi-threaded program: all its state is global and visible
+ as a multi-threaded program: its state is global and visible
in all executions contexts
\item Concurrency arises because of
\begin{itemize}
@@ -33,9 +33,7 @@
\begin{frame}[fragile]
\frametitle{Linux mutexes}
\begin{itemize}
- \item The main locking primitive since Linux 2.6.16.
- \item The kernel used to have semaphores only, and mutexes have been
- introduced as a simplification of binary semaphores.
+ \item The kernel's main locking primitive
\item The process requesting the lock blocks when the lock is
already held. Mutexes can therefore only be used in contexts
where sleeping is allowed.
@@ -65,7 +63,7 @@
\end{itemize}
\item \mint{c}+int mutex_lock_killable(struct mutex *lock);+
\begin{itemize}
- \item Same, but can be interrupted by a fatal (SIGKILL) signal. If
+ \item Same, but can be interrupted by a fatal (\code{SIGKILL}) signal. If
interrupted, returns a non zero value and doesn't hold the
lock. Test the return value!!!
\end{itemize}
diff --git a/slides/sysdev-embedded-linux/sysdev-embedded-linux.tex b/slides/sysdev-embedded-linux/sysdev-embedded-linux.tex
index 046146f..8ffd204 100644
--- a/slides/sysdev-embedded-linux/sysdev-embedded-linux.tex
+++ b/slides/sysdev-embedded-linux/sysdev-embedded-linux.tex
@@ -473,7 +473,7 @@ met:
\item {\bf gpsd}, a daemon to interpret and share GPS data
\item {\bf hal}, the Hardware Abstraction Layer suite. A daemon that
receives hardware notifications, maintains a database of available
- hardware devices and offers a D-Bus interface
+ hardware devices and offers a \code{dbus} interface
\item {\bf libraw1394}, raw access to Firewire devices
\item {\bf libusb}, a userspace library for accessing USB devices
without writing an in-kernel driver
@@ -978,12 +978,12 @@ met:
\begin{itemize}
\item Event handling to detect SD card insertion
\begin{itemize}
- \item udev, that receives events from the kernel, creates device
- nodes, and sends events to HAL
- \item HAL, which maintains a database of available devices and
- provides a D-Bus API
- \item D-Bus to connect HAL with the application. The application
- subscribes to HAL event through D-Bus and gets notified when
+ \item \code{udev}, that receives events from the kernel, creates device
+ nodes, and sends events to \code{hal}
+ \item \code{hal}, which maintains a database of available devices and
+ provides a \code{dbus} API
+ \item \code{dbus} to connect \code{hal} with the application. The application
+ subscribes to \code{hal} event through \code{dbus} and gets notified when
they are triggered
\item Components: {\bf udev}, {\bf hal}, {\bf dbus}
\end{itemize}
diff --git a/slides/sysdev-root-filesystem-virtual-fs/sysdev-root-filesystem-virtual-fs.tex b/slides/sysdev-root-filesystem-virtual-fs/sysdev-root-filesystem-virtual-fs.tex
index 5b9f1d4..aa73fa4 100644
--- a/slides/sysdev-root-filesystem-virtual-fs/sysdev-root-filesystem-virtual-fs.tex
+++ b/slides/sysdev-root-filesystem-virtual-fs/sysdev-root-filesystem-virtual-fs.tex
@@ -55,7 +55,8 @@
\item It allows to represent in userspace the vision that the kernel
has of the buses, devices and drivers in the system
\item It is useful for various userspace applications that need to
- list and query the available hardware, for example udev or mdev
+ list and query the available hardware, for example \code{udev} or
+ \code{mdev}.
\item All applications using sysfs expect it to be mounted in the
\code{/sys} directory
\item Command to mount \code{/sys}:\\
diff --git a/slides/sysdev-udev/sysdev-udev.tex b/slides/sysdev-udev/sysdev-udev.tex
index c99fafb..31861a7 100644
--- a/slides/sysdev-udev/sysdev-udev.tex
+++ b/slides/sysdev-udev/sysdev-udev.tex
@@ -69,7 +69,7 @@ drwxr-xr-x 2 root root 4096 2011-04-07 14:43 shm
subscribe to notifications of filesystem changes.
\item When an event is received, \code{udevd} starts a process to:
\begin{itemize}
- \item try to match the event against udev rules,
+ \item try to match the event against \code{udev} rules,
\item create / remove device files,
\item and run programs (to load / remove a driver, to notify user
space...)
@@ -104,7 +104,7 @@ recv(4,
\begin{frame}
\frametitle{udev rules}
- When a udev rule matching event information is found, it can be
+ When a \code{udev} rule matching event information is found, it can be
used:
\begin{itemize}
\item To define the name and path of a device file.
@@ -223,7 +223,7 @@ ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -Q $env{MODALIAS}"
\frametitle{Cold-plugging}
\begin{itemize}
\item Issue: loosing all device events happening during kernel
- initialization, because udev is not ready yet.
+ initialization, because \code{udev} is not ready yet.
\item Solution: after starting \code{udevd}, have the kernel emit
uevents for all devices present in \code{/sys}.
\item This can be done by the \code{udevtrigger} utility.
@@ -257,7 +257,7 @@ UDEV [1170452995.568758] add@/class/input/input28/ts2
\end{block}
It gives time information measured in microseconds. You can measure
time elapsed between the uevent (\code{UEVENT} line), and the completion of
-the corresponding udev process (matching \code{UDEV} line).
+the corresponding \code{udev} process (matching \code{UDEV} line).
\end{frame}
\begin{frame}[fragile]
@@ -322,18 +322,18 @@ UDEVD_EVENT=1
\frametitle{udev files}
\begin{itemize}
\item \code{/etc/udev/udev.conf}\\
- udev configuration file.\\
+ \code{udev} configuration file.\\
Mainly used to configure syslog reporting priorities.\\
Example setting: \code{udev_log="err"}
\item \code{/lib/udev/rules.d/}\\
- Standard udev event matching rules, installed by the distribution.
+ Standard \code{udev} event matching rules, installed by the distribution.
\item \code{/etc/udev/rules.d/*.rules}\\
- Local (custom) udev event matching rules. Best to modify these.
+ Local (custom) \code{udev} event matching rules. Best to modify these.
\item \code{/lib/udev/devices/*}\\
static \code{/dev} content (such as \code{/dev/console},
\code{/dev/null}...).
\item \code{/lib/udev/*}\\
- helper programs called from udev rules.
+ helper programs called from \code{udev} rules.
\item \code{/dev/*}\\
Created device files.
\end{itemize}
@@ -381,7 +381,7 @@ CONFIG_RAMFS=y
\url{http://kernel.org/pub/linux/utils/kernel/hotplug/udev.html}
\item Sources\\
\url{http://kernel.org/pub/linux/utils/kernel/hotplug/}
- \item The udev manual page:\\
+ \item The \code{udev} manual page:\\
\code{man udev}
\end{itemize}
\end{frame}
@@ -390,12 +390,13 @@ CONFIG_RAMFS=y
\frametitle{mdev, the udev for embedded systems}
\begin{itemize}
\item {\em udev} might be too heavy-weight for some embedded
- systems, the udevd daemon staying in the background waiting for
+ systems, the \code{udevd} daemon staying in the background waiting for
events.
- \item BusyBox provides a simpler alternative called {\bf mdev},
- available by enabling the MDEV configuration option.
- \item mdev's usage is documented in \code{doc/mdev.txt} in the BusyBox source code.
- \item mdev is also able to load firmware to the kernel like udev
+ \item BusyBox provides a simpler alternative called \code{mdev},
+ available by enabling the \code{MDEV} configuration option.
+ \item \code{mdev}'s usage is documented in \code{doc/mdev.txt} in the BusyBox source code.
+ \item\code{mdev}mdev is also able to load firmware to the kernel like
+ \code{udev}
\end{itemize}
\end{frame}
@@ -403,13 +404,13 @@ CONFIG_RAMFS=y
\frametitle{mdev usage}
\begin{itemize}
\item To use \code{mdev}, the \code{proc} and \code{sysfs} filesystems must be mounted
- \item mdev must be enabled as the hotplug event manager\\
+ \item \code{mdev} must be enabled as the hotplug event manager\\
\code{echo /sbin/mdev > /proc/sys/kernel/hotplug}
\item Need to mount \code{/dev} as a \code{tmpfs}:\\
\code{mount -t tmpfs mdev /dev}
\item Tell \code{mdev} to create the \code{/dev} entries
corresponding to the devices detected
- during boot when mdev was not running:\\
+ during boot when \code{mdev} was not running:\\
\code{mdev -s}
\item The behavior is specified by the \code{/etc/mdev.conf} configuration
file, with the following format\\
More information about the training-materials-updates
mailing list