[bootlin/training-materials updates] master: Kernel slides and labs: misc minor improvements (64803863)
Michael Opdenacker
michael.opdenacker at bootlin.com
Fri Feb 5 12:59:56 CET 2021
Repository : https://github.com/bootlin/training-materials
On branch : master
Link : https://github.com/bootlin/training-materials/commit/64803863238d5f1e1434f7ad74dae135e21a820c
>---------------------------------------------------------------
commit 64803863238d5f1e1434f7ad74dae135e21a820c
Author: Michael Opdenacker <michael.opdenacker at bootlin.com>
Date: Fri Feb 5 12:59:56 2021 +0100
Kernel slides and labs: misc minor improvements
Signed-off-by: Michael Opdenacker <michael.opdenacker at bootlin.com>
>---------------------------------------------------------------
64803863238d5f1e1434f7ad74dae135e21a820c
labs/kernel-debugging/kernel-debugging.tex | 6 +++---
slides/kernel-device-model/kernel-device-model.tex | 21 +++++++++++++--------
.../kernel-driver-development-concurrency.tex | 18 ++++++++----------
.../kernel-driver-development-debugging.tex | 10 ++++++----
.../kernel-driver-development-interrupts.tex | 2 +-
.../kernel-driver-development-memory.tex | 5 ++++-
.../kernel-driver-development-modules.tex | 12 +++++++-----
slides/kernel-frameworks/kernel-frameworks.tex | 4 ++--
slides/kernel-frameworks2/kernel-frameworks2.tex | 3 +--
slides/kernel-i2c/kernel-i2c.tex | 4 ++--
.../kernel-porting-content.tex | 8 ++++----
slides/sysdev-device-files/sysdev-device-files.tex | 2 +-
12 files changed, 52 insertions(+), 43 deletions(-)
diff --git a/labs/kernel-debugging/kernel-debugging.tex b/labs/kernel-debugging/kernel-debugging.tex
index 7e4f7773..2a3af485 100644
--- a/labs/kernel-debugging/kernel-debugging.tex
+++ b/labs/kernel-debugging/kernel-debugging.tex
@@ -14,7 +14,7 @@ each character being received.
Check what happens with your module. Do you see the debugging messages
that you added? Your kernel probably does not have
\kconfig{CONFIG_DYNAMIC_DEBUG} set and your driver is not compiled with
-\code{DEBUG} defined., so you shouldn't see any message.
+\code{DEBUG} defined, so you shouldn't see any message.
Now, recompile your kernel with the following options:
@@ -29,7 +29,7 @@ Now, recompile your kernel with the following options:
Once this is done, in U-Boot, add \code{loglevel=8} to the kernel
command line to get the debugging messages directly in the console
-(otherwise you will only see them in \code{dmesg}.
+(otherwise you will only see them in \code{dmesg}).
Now boot your updated kernel.
@@ -148,5 +148,5 @@ you are working on helps, but seeing the original C code should answer
most questions.
Note that the same technique works if the error comes directly from
-the code of a module. Just dissassemble the \code{.o} file from which
+the code of a module. Just dissassemble the \code{.o} file
the \code{.ko} file was generated from.
diff --git a/slides/kernel-device-model/kernel-device-model.tex b/slides/kernel-device-model/kernel-device-model.tex
index cb26eea8..380eb6ba 100644
--- a/slides/kernel-device-model/kernel-device-model.tex
+++ b/slides/kernel-device-model/kernel-device-model.tex
@@ -195,10 +195,11 @@ static struct usb_driver rtl8150_driver = {
\end{frame}
\begin{frame}[fragile]
- \frametitle{Driver (Un)Registration}
+ \frametitle{Driver registration and unregistration}
\begin{itemize}
- \item When the driver is loaded or unloaded, it must register or
- unregister itself from the USB core
+ \small
+ \item When the driver is loaded / unloaded, it must register /
+ unregister itself to / from the USB core
\item Done using \kfunc{usb_register} and \kfunc{usb_deregister},
provided by the USB core.
\begin{block}{}
@@ -217,8 +218,12 @@ module_init(usb_rtl8150_init);
module_exit(usb_rtl8150_exit);
\end{minted}
\end{block}
-\item Note: this code has now been replaced by a shorter
- \kfunc{module_usb_driver} macro call.
+\item All this code is actually replaced by a call to the \kfunc{module_usb_driver} macro:
+ \begin{block}{}
+\begin{minted}[fontsize=\scriptsize]{c}
+module_usb_driver(rtl8150_driver);
+\end{minted}
+\end{block}
\end{itemize}
\end{frame}
@@ -770,9 +775,9 @@ static struct platform_driver serial_omap_driver = {
\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 (\code{net},
- \code{input}, \code{block}...), whatever bus they are connected
- to. Very useful!
+ \item \code{/sys/class} enumerates devices by the framework they are
+ registered to (\code{net}, \code{input}, \code{block}...),
+ whatever bus they are connected to. Very useful!
\end{itemize}
\item Take your time to explore \code{/sys} on your workstation.
\end{itemize}
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 e193ad33..83d2d4ad 100644
--- a/slides/kernel-driver-development-concurrency/kernel-driver-development-concurrency.tex
+++ b/slides/kernel-driver-development-concurrency/kernel-driver-development-concurrency.tex
@@ -246,17 +246,15 @@ static unsigned int ulite_tx_empty
\begin{frame}
\frametitle{Alternatives to Locking}
+ As we have just seen, locking can have a strong negative
+ impact on system performance. In some situations, you could do
+ without it.
\begin{itemize}
- \item As we have just seen, locking can have a strong negative
- impact on system performance. In some situations, you could do
- without it.
- \begin{itemize}
- \item By using lock-free algorithms like \emph{Read Copy Update}
- (RCU).
- \item RCU API available in the kernel (See
- \url{https://en.wikipedia.org/wiki/RCU}).
- \item When available, use atomic operations.
- \end{itemize}
+ \item By using lock-free algorithms like \emph{Read Copy Update}
+ (RCU).
+ \item RCU API available in the kernel (See
+ \url{https://en.wikipedia.org/wiki/Read-copy-update}).
+ \item When available, use atomic operations.
\end{itemize}
\end{frame}
diff --git a/slides/kernel-driver-development-debugging/kernel-driver-development-debugging.tex b/slides/kernel-driver-development-debugging/kernel-driver-development-debugging.tex
index 5d621192..31d1536a 100644
--- a/slides/kernel-driver-development-debugging/kernel-driver-development-debugging.tex
+++ b/slides/kernel-driver-development-debugging/kernel-driver-development-debugging.tex
@@ -36,7 +36,7 @@ pr_info("Booting CPU %d\n", cpu);
\begin{itemize}
\item They take a pointer to \kstruct{device} as first
argument, and then a format string with arguments
- \item Defined in \kfile{include/linux/device.h}
+ \item Defined in \kfile{include/linux/dev_printk.h}
\item To be used in drivers integrated with the Linux device
model
\item Example:
@@ -165,15 +165,17 @@ dev_info(&pdev->dev, "in probe\n");
\end{itemize}
\end{frame}
-\begin{frame}
+\begin{frame}[fragile]
\frametitle{Using Magic SysRq}
+ Functionnality provided by serial drivers
\begin{itemize}
\item Allows to run multiple debug / rescue commands even when the
kernel seems to be in deep trouble
\begin{itemize}
\item On PC: press \code{[Alt]} + \code{[Prnt Scrn]} + \code{<character>}
- simultaneously (\code{[SysRq]} = \code{[Alt]} + \code{[Prnt Scrn]})
- \item On embedded: in the console, send a break character
+ simultaneously\\
+ (\code{[SysRq]} = \code{[Alt]} + \code{[Prnt Scrn]})
+ \item On embedded: in the console, send a break character\\
(Picocom: press \code{[Ctrl]} + \code{a} followed by \code{[Ctrl]}
+ \code{\ }), then press \code{<character>}
\end{itemize}
diff --git a/slides/kernel-driver-development-interrupts/kernel-driver-development-interrupts.tex b/slides/kernel-driver-development-interrupts/kernel-driver-development-interrupts.tex
index 16737b2c..1f70821d 100644
--- a/slides/kernel-driver-development-interrupts/kernel-driver-development-interrupts.tex
+++ b/slides/kernel-driver-development-interrupts/kernel-driver-development-interrupts.tex
@@ -269,7 +269,7 @@ static void atmel_sha_done_task(unsigned long data)
/* Probe function: registering the tasklet */
static int atmel_sha_probe(struct platform_device *pdev)
{
- struct atmel_sha_dev *sha_dd;
+ struct atmel_sha_dev *sha_dd; // Per device structure
[...]
platform_set_drvdata(pdev, sha_dd);
[...]
diff --git a/slides/kernel-driver-development-memory/kernel-driver-development-memory.tex b/slides/kernel-driver-development-memory/kernel-driver-development-memory.tex
index dd8762cb..7b26639e 100644
--- a/slides/kernel-driver-development-memory/kernel-driver-development-memory.tex
+++ b/slides/kernel-driver-development-memory/kernel-driver-development-memory.tex
@@ -97,7 +97,7 @@
\end{center}
\end{frame}
-\begin{frame}
+\begin{frame}[fragile]
\frametitle{Page Allocator}
\begin{itemize}
\item Appropriate for medium-size allocations
@@ -115,6 +115,9 @@
\begin{itemize}
\item This means that large areas may not be available or hard to
retrieve due to physical memory fragmentation.
+ \item The {\em Contiguous Memory Allocator} is a solution to
+ satisfy requests for large contiguous areas (see
+ \url{https://lwn.net/Articles/486301/}).
\end{itemize}
\end{itemize}
\end{frame}
diff --git a/slides/kernel-driver-development-modules/kernel-driver-development-modules.tex b/slides/kernel-driver-development-modules/kernel-driver-development-modules.tex
index 849bf9af..007b8b19 100644
--- a/slides/kernel-driver-development-modules/kernel-driver-development-modules.tex
+++ b/slides/kernel-driver-development-modules/kernel-driver-development-modules.tex
@@ -202,11 +202,11 @@ endif
\end{itemize}
\end{frame}
-\begin{frame}
+\begin{frame}[fragile]
\frametitle{Modules and Kernel Version}
\begin{itemize}
- \item To be compiled, a kernel module needs access to the kernel
- headers, containing the definitions of functions, types and
+ \item To be compiled, a kernel module needs access to {\em kernel
+ headers}, containing the definitions of functions, types and
constants.
\item Two solutions
\begin{itemize}
@@ -214,12 +214,14 @@ endif
(configured + \code{make modules_prepare})
\item Only kernel headers (\code{linux-headers-*} packages in
Debian/Ubuntu distributions, or directory created by \code{make
- headers_install})
+ headers_install}).
\end{itemize}
- \item The sources or headers must be configured
+ \item The sources or headers must be configured (\code{.config} file)
\begin{itemize}
\item Many macros or functions depend on the configuration
\end{itemize}
+ \item You also need the kernel \kfile{Makefile}, the \kdir{scripts}
+ directory, and a few others.
\item A kernel module compiled against version X of kernel headers
will not load in kernel version Y
\begin{itemize}
diff --git a/slides/kernel-frameworks/kernel-frameworks.tex b/slides/kernel-frameworks/kernel-frameworks.tex
index b398a318..1a66732f 100644
--- a/slides/kernel-frameworks/kernel-frameworks.tex
+++ b/slides/kernel-frameworks/kernel-frameworks.tex
@@ -46,8 +46,8 @@
identified using a {\em major} and a {\em minor} number.
\item The {\em major number} typically indicates the family of the
device.
- \item The {\em minor number} typically indicates the number of the
- device (when there are for example several serial ports)
+ \item The {\em minor number} allows drivers to distinguish
+ the various devices they manage.
\item Most major and minor numbers are statically allocated, and
identical across all Linux systems.
\item They are defined in \kerneldochtml{admin-guide/devices}.
diff --git a/slides/kernel-frameworks2/kernel-frameworks2.tex b/slides/kernel-frameworks2/kernel-frameworks2.tex
index 7c1d9131..1431e83a 100644
--- a/slides/kernel-frameworks2/kernel-frameworks2.tex
+++ b/slides/kernel-frameworks2/kernel-frameworks2.tex
@@ -347,8 +347,7 @@ static struct fb_ops xxxfb_ops = {
\item In the \code{probe()} function, registration of the
framebuffer device and operations
\begin{minted}[fontsize=\footnotesize]{c}
-static int xxxfb_probe (struct pci_dev *dev,
- const struct pci_device_id *ent)
+static int xxxfb_probe (struct pci_dev *dev, const struct pci_device_id *ent)
{
struct fb_info *info;
[...]
diff --git a/slides/kernel-i2c/kernel-i2c.tex b/slides/kernel-i2c/kernel-i2c.tex
index 4b1cf9ea..a74a784f 100644
--- a/slides/kernel-i2c/kernel-i2c.tex
+++ b/slides/kernel-i2c/kernel-i2c.tex
@@ -37,8 +37,8 @@
\item The I2C controller drivers are located in
\kdir{drivers/i2c/busses}.
\item The I2C device drivers are located throughout
- \kdir{drivers}, depending on the type of device (ex:
- \kdir{drivers/input} for input devices).
+ \kdir{drivers}, depending on the framework used to expose the
+ devices (e.g. \kdir{drivers/input} for input devices).
\end{itemize}
\end{frame}
diff --git a/slides/kernel-porting-content/kernel-porting-content.tex b/slides/kernel-porting-content/kernel-porting-content.tex
index a8ff2865..8f45e575 100644
--- a/slides/kernel-porting-content/kernel-porting-content.tex
+++ b/slides/kernel-porting-content/kernel-porting-content.tex
@@ -14,7 +14,7 @@
\item For example, some architectures use the Device Tree, some do
not.
\end{itemize}
- \item This presentation is focused on the ARM architecture only
+ \item This presentation is focused on the \code{arm} (32 bit) architecture only
\end{itemize}
\end{frame}
@@ -460,12 +460,12 @@ MACHINE_END
\end{frame}
\begin{frame}
- \frametitle{Adding device drivers}
+ \frametitle{Adding controller drivers}
Once the core pieces of the SoC support have been implemented, the
remaining part is to add drivers for the different hardware blocks:
\begin{itemize}
- \item Ethernet driver, in \kfile{drivers/net/ethernet/marvell/mvneta.c}
- \item SATA driver, in \kfile{drivers/ata/sata_mv.c}
+ \item Ethernet controller driver, in \kfile{drivers/net/ethernet/marvell/mvneta.c}
+ \item SATA controller driver, in \kfile{drivers/ata/sata_mv.c}
\item I2C controller driver, in \kfile{drivers/i2c/busses/i2c-mv64xxx.c}
\item SPI controller driver, in \kfile{drivers/spi/spi-orion.c}
\item PCIe controller driver, in \kfile{drivers/pci/controller/pci-mvebu.c}
diff --git a/slides/sysdev-device-files/sysdev-device-files.tex b/slides/sysdev-device-files/sysdev-device-files.tex
index caeeabc5..edd8ab67 100644
--- a/slides/sysdev-device-files/sysdev-device-files.tex
+++ b/slides/sysdev-device-files/sysdev-device-files.tex
@@ -57,7 +57,7 @@ close(fd);
kernel was left to the system developer
\end{itemize}
\item The \code{devtmpfs} virtual filesystem can be mounted on
- \code{/dev} and contains all the devices known to the kernel.
+ \code{/dev} and contains all the devices registered to kernel frameworks.
The \kconfig{CONFIG_DEVTMPFS_MOUNT} kernel configuration option
makes the kernel mount it automatically at boot time, except
when booting on an initramfs.
More information about the training-materials-updates
mailing list