[bootlin/training-materials updates] master: kernel-source: Rework the slide about proprietary modules a bit (bdf04db9)

[Miquel Raynal]

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

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

commit bdf04db90a224089e414a5c469fcb8fe8e2dd7e4
Author: Miquel Raynal <miquel.raynal at bootlin.com>
Date:   Wed Jan 18 12:14:09 2023 +0100

    kernel-source: Rework the slide about proprietary modules a bit
    
    Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>


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

bdf04db90a224089e414a5c469fcb8fe8e2dd7e4
 .../kernel-source-code-drivers.tex                 | 51 +++++++++++++++-------
 1 file changed, 36 insertions(+), 15 deletions(-)

diff --git a/slides/kernel-source-code-drivers/kernel-source-code-drivers.tex b/slides/kernel-source-code-drivers/kernel-source-code-drivers.tex
index 347b9185..938a5d03 100644
--- a/slides/kernel-source-code-drivers/kernel-source-code-drivers.tex
+++ b/slides/kernel-source-code-drivers/kernel-source-code-drivers.tex
@@ -165,31 +165,52 @@
 
 \begin{frame}
   \frametitle{Proprietary code and the kernel}
-  \begin{columns}
-    \column{0.75\textwidth}
   \begin{itemize}
   \item It is illegal to distribute a binary kernel that includes
     statically compiled proprietary drivers
-  \item The kernel modules are a gray area: are they derived works of
-    the kernel or not?
+  \item The kernel modules are a gray area: unclear if they are legal or not
     \begin{itemize}
     \item The general opinion of the kernel community is that
       proprietary modules are bad: \kdochtml{process/kernel-driver-statement}
     \item From a legal point of view, each driver is probably a
-      different case
-    \item Is it really useful to keep your drivers secret?
+      different case:
+      \begin{itemize}
+      \item Are they derived works of the kernel?
+      \item Are they designed to be used with another operating system?
+      \end{itemize}
     \end{itemize}
-  \item There are some examples of proprietary drivers, like the
-    Nvidia graphics drivers
+  \item Is it really useful to keep drivers secret anyway?
+  \end{itemize}
+\end{frame}
+
+\begin{frame}
+  \frametitle{Abusing the kernel licensing constraints}
+  \begin{columns}
+    \column{0.5\textwidth}
     \begin{itemize}
-    \item They use a wrapper between the driver and the kernel
-    \item Unclear whether it makes it legal or not
-    \item Pre-compiled drivers work with only one kernel version, kernel
-      updates, even minors, might just become impossible.
+    \item There are some examples of proprietary drivers
+      \begin{itemize}
+      \item Nvidia uses a wrapper between their drivers and the kernel
+      \item They claim the drivers could be used with a different OS
+        with another wrapper
+      \item Unclear whether it makes it legal or not
+      \end{itemize}
     \end{itemize}
-  \end{itemize}
-    \column{0.25\textwidth}
-    \includegraphics[height=0.85\textheight]{slides/kernel-source-code-drivers/binary-blobs.pdf}
+    \begin{center}
+    \includegraphics[height=0.3\textheight]{slides/kernel-source-code-drivers/binary-blobs.pdf}
+    \end{center}
+    \column{0.5\textwidth}
+    \begin{itemize}
+    \item The current trend is to hide the logic in the firmware or in
+      userspace. The GPL kernel driver is almost empty and either:
+      \begin{itemize}
+      \item Blindly writes an incoming flow of bytes in the hardware
+      \item Exposes a huge MMIO region to userspace through \code{mmap}
+      \end{itemize}
+    \end{itemize}
+    \begin{center}
+    \includegraphics[height=0.3\textheight]{slides/kernel-source-code-drivers/empty-modules.pdf}
+    \end{center}
   \end{columns}
 \end{frame}