[bootlin/training-materials updates] master: Kernel labs and slides: misc updates and improvements (a5e5bfd4)

[Michael Opdenacker]

Repository : https://github.com/bootlin/training-materials
On branch  : master
Link       : https://github.com/bootlin/training-materials/commit/a5e5bfd4965bf89a8db68f09a6aa0e37206edf0a

>---------------------------------------------------------------

commit a5e5bfd4965bf89a8db68f09a6aa0e37206edf0a
Author: Michael Opdenacker <michael.opdenacker at bootlin.com>
Date:   Fri Feb 5 11:09:16 2021 +0100

    Kernel labs and slides: misc updates and improvements
    
    Signed-off-by: Michael Opdenacker <michael.opdenacker at bootlin.com>


>---------------------------------------------------------------

a5e5bfd4965bf89a8db68f09a6aa0e37206edf0a
 .../kernel-i2c-communication.tex                        |  2 +-
 .../kernel-i2c-input-interface.tex                      |  9 ++++-----
 .../kernel-driver-development-memory.tex                |  9 +++++----
 slides/kernel-frameworks2/kernel-frameworks2.tex        | 17 +++++++++--------
 4 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/labs/kernel-i2c-communication/kernel-i2c-communication.tex b/labs/kernel-i2c-communication/kernel-i2c-communication.tex
index 9f9b99a7..41aba5d0 100644
--- a/labs/kernel-i2c-communication/kernel-i2c-communication.tex
+++ b/labs/kernel-i2c-communication/kernel-i2c-communication.tex
@@ -268,7 +268,7 @@ the state of its internal registers only when they have been read.
 As a consequence, we will need to read the registers twice!
 
 To keep the code simple and readable, let's create a
-\code{nunchuk_read_registers} function to read the registers once.
+\code{nunchuk_read_registers()} function to read the registers once.
 In this function:
 
 \begin{enumerate}
diff --git a/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex b/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex
index ee2f463b..d4e5938c 100644
--- a/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex
+++ b/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex
@@ -20,7 +20,7 @@ its state has changed. Therefore, the only way to access device data
 and detect changes is to regularly poll its registers, using the input
 polling API described in the lectures.
 
-Rebuild your kernel with static support event interface
+Rebuild your kernel with static event interface
 (\kconfig{CONFIG_INPUT_EVDEV}) support. With the default
 configuration, this feature is available as a module, which is less
 convenient.
@@ -90,8 +90,7 @@ course):
 
 Recompile and reload your driver. You should now see in the kernel log
 that the \code{Unspecified device} type is replaced by
-\code{Wii Nunchuk} and that the physical path of the device is reported
-too.
+\code{Wii Nunchuk}.
 
 \section{Implement the polling routine}
 
@@ -99,7 +98,7 @@ It's time to implement the routine which will poll the nunchuk registers
 at a regular interval.
 
 Create a \code{nunchuk_poll()} function with the right prototype (find
-it by looking at the definition of the \ksym{input_setup_polling} function.)
+it by looking at the definition of the \kfunc{input_setup_polling} function.)
 
 In this function, you will have to read the nunchuk registers. However,
 as you can see, the prototype of the \code{poll_fn()} routine doesn't
@@ -119,7 +118,7 @@ have an event on the logical side (such as running the polling
 function), we can find out which I2C device this corresponds to,
 to communicate with the hardware.
 
-This need is typically implemented by creating a {\em private} data
+This need is typically implemented by creating a per device, {\em private} data
 structure to manage our device and implement such pointers between
 the physical and logical worlds.
 
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 d62c7a92..dd8762cb 100644
--- a/slides/kernel-driver-development-memory/kernel-driver-development-memory.tex
+++ b/slides/kernel-driver-development-memory/kernel-driver-development-memory.tex
@@ -110,7 +110,7 @@
   \item Typical maximum size is 8192 KB, but it might depend on the
     kernel configuration.
   \item The allocated area is contiguous in the kernel virtual address
-    space, but also maps to also physically contiguous pages. It is
+    space, but also maps to physically contiguous pages. It is
     allocated in the identity-mapped part of the kernel memory space.
     \begin{itemize}
     \item This means that large areas may not be available or hard to
@@ -354,9 +354,10 @@ kfree(work);
     \begin{itemize}
     \item Dynamic memory error detector, to find use-after-free and
       out-of-bounds bugs.
-    \item Only available on \code{x86_64}, \code{arm64}, \code{s390} and
-      \code{xtensa} so far (Linux 4.20 status), but will help to improve
-      architecture independent code anyway.
+    \item Only available on \code{x86} (64 bit), \code{arm64}, \code{riscv}
+      (64 bit), \code{powerpc} (32 bit), \code{s390} and \code{xtensa} so far
+      (Linux 5.11 status), but will help to improve architecture independent
+      code anyway.
     \item See \kerneldochtml{dev-tools/kasan} for details.
     \end{itemize}
   \item \code{Kmemleak}
diff --git a/slides/kernel-frameworks2/kernel-frameworks2.tex b/slides/kernel-frameworks2/kernel-frameworks2.tex
index e1de8677..7c1d9131 100644
--- a/slides/kernel-frameworks2/kernel-frameworks2.tex
+++ b/slides/kernel-frameworks2/kernel-frameworks2.tex
@@ -313,8 +313,9 @@ int main(void)
 
 \begin{frame}[fragile]
   \frametitle{Framebuffer driver operations}
-  Here are the operations a framebuffer driver can or must
+  \small Here are the operations a framebuffer driver can or must
   implement, and define them in a \kstruct{fb_ops} structure
+  (excerpt from \kfile{drivers/video/fbdev/skeletonfb.c})
   \footnotesize
   \begin{minted}[fontsize=\scriptsize]{c}
 static struct fb_ops xxxfb_ops = {
@@ -328,10 +329,10 @@ static struct fb_ops xxxfb_ops = {
     .fb_setcolreg = xxxfb_setcolreg,
     .fb_blank = xxxfb_blank,
     .fb_pan_display = xxxfb_pan_display,
-    .fb_fillrect = xxxfb_fillrect,   /* Needed !!! */
-    .fb_copyarea = xxxfb_copyarea,   /* Needed !!! */
-    .fb_imageblit = xxxfb_imageblit, /* Needed !!! */
-    .fb_cursor = xxxfb_cursor,       /* Optional !!! */
+    .fb_fillrect = xxxfb_fillrect,             /* Needed !!! */
+    .fb_copyarea = xxxfb_copyarea,             /* Needed !!! */
+    .fb_imageblit = xxxfb_imageblit,           /* Needed !!! */
+    .fb_cursor = xxxfb_cursor,                 /* Optional !!! */
     .fb_rotate = xxxfb_rotate,
     .fb_sync = xxxfb_sync,
     .fb_ioctl = xxxfb_ioctl,
@@ -360,9 +361,9 @@ static int xxxfb_probe (struct pci_dev *dev,
     [...]
 }
   \end{minted}
-  \item \kfunc{register_framebuffer} will create the character device
-    that can be used by user space applications with the generic
-    framebuffer API.
+  \item \kfunc{register_framebuffer} will create a new character device
+    in {\em devtmpfs} that can be used by user space applications
+    with the generic framebuffer API.
 \end{itemize}
 \end{frame}