diff --git a/.mailmap b/.mailmap deleted file mode 100644 index 250d9d1..0000000 --- a/.mailmap +++ /dev/null @@ -1,30 +0,0 @@ -Jian-Xing Wu 吳建興 -Meng-Zong Tsai fennecJ <58484289+fennecJ@users.noreply.github.com> -Meng-Zong Tsai fennecJ -Jim Huang Jim Huang -Jim Huang Jim Huang -Chih-En Lin linD026 -Chih-En Lin linD026 <66012716+linD026@users.noreply.github.com> -Chih-En Lin linD026 <0086d026@email.ntou.edu.tw> -Chih-En Lin linzhien <0086d026@email.ntou.edu.tw> -mengxinayan <31788564+mengxinayan@users.noreply.github.com> 萌新阿岩 -Ethan Chan tzuyichan -Peter Lin lyctw -Peter Lin Peter Lin -Che-Chia Chang gagachang -Shao-Tse Hung ccs100203 -Yi-Wei Lin RinHizakura -Chih-Hsuan Yang 25077667 -Yin-Chiuan Chen leovincentseles -Xatierlike Lee xatier -Chin Yik Ming ChinYikMing -Tse-Wei Lin <20110901eric@outlook.com> 2011eric -Yu-Hsiang Tseng asas1asas200 -Kuan-Wei Chiu visitorckw -I-Hsin Cheng vax-r -Wei-Hsin Yeh weihsinyeh -Wei-Hsin Yeh weihsinyeh <90430653+weihsinyeh@users.noreply.github.com> -Cheng-Shian Yeh yeh-sudo -Yo-Jung Lin <0xff07@gmail.com> 0xff07 -YYGO srayuws -Yen-Yu Chen <69316865+YLowy@users.noreply.github.com> Ylowy diff --git a/Makefile b/Makefile deleted file mode 100644 index f945660..0000000 --- a/Makefile +++ /dev/null @@ -1,24 +0,0 @@ -PROJ = lkmpg -all: $(PROJ).pdf - -$(PROJ).pdf: lkmpg.tex - @if ! hash latexmk; then echo "No Latexmk found. See https://mg.readthedocs.io/latexmk.html for installation."; exit 1; fi - rm -rf _minted-$(PROJ) - latexmk -shell-escape lkmpg.tex -pdf - -html: lkmpg.tex html.cfg assets/Manrope_variable.ttf - sed $ 's/\t/ /g' lkmpg.tex > lkmpg-for-ht.tex - make4ht --shell-escape --utf8 --format html5 --config html.cfg --output-dir html lkmpg-for-ht.tex "fn-in" - ln -sf lkmpg-for-ht.html html/index.html - cp assets/Manrope_variable.ttf html/Manrope_variable.ttf - rm -f lkmpg-for-ht.tex lkmpg-for-ht.xref lkmpg-for-ht.tmp lkmpg-for-ht.html lkmpg-for-ht.css lkmpg-for-ht.4ct lkmpg-for-ht.4tc lkmpg-for-ht.dvi lkmpg-for-ht.lg lkmpg-for-ht.idv lkmpg*.svg lkmpg-for-ht.log lkmpg-for-ht.aux - rm -rf _minted-$(PROJ) _minted-lkmpg-for-ht - -indent: - (cd examples; find . -name '*.[ch]' | xargs clang-format -i) - -clean: - rm -f *.dvi *.aux *.log *.ps *.pdf *.out lkmpg.bbl lkmpg.blg lkmpg.lof lkmpg.toc lkmpg.fdb_latexmk lkmpg.fls lkmpg-* - rm -rf html - -.PHONY: html diff --git a/README.md b/README.md index 33db249..eac4c1a 100644 --- a/README.md +++ b/README.md @@ -2,25 +2,25 @@ # Linux 内核模块编程指南 -该项目不断更新《Linux 内核模块编程指南》，并提供最新 5.x 和 6.x 内核版本的[示例](examples/)。该指南自 2001 年开始发布，网络上的大多数副本只介绍了旧的 2.6.x 内核。 +该项目是不断更新《Linux 内核模块编程指南》的中文译本, 但需要注意的是此项目和原版在使用的中央处理器架构上有所不同, 原版是使用的主流X86架构, 本版本会将部分涉及到架构相关的内容修改为龙架构，目前本译本已支持到 6.9.x 版本的内核, 相关[示例](示例/)。 -中文翻译会根据受限于译者的理解能力可能会出现一些误差, 如有能力可以查看[英文原版](https://sysprog21.github.io/lkmpg/#kernel-module-package) +本项目原版是使用TeXLie格式编写, 在译者对此格式较为陌生, 已改为更为主流的 `markdown` 格式重写, 并且在翻译途中为了方便读者理解一些不常见的英文缩写, 添加了部分注释 ## 开始使用 -### 概述 +在线文档: http://223.76.216.188:50201/books/linux/chapter/6c4b7 -1. 获取最新源代码(相信你能看到这个说明就已经有源码了) -2. 安装先决条件 - > 要从源代码生成图书，需要使用 make 和 [TeXLive](https://www.tug.org/texlive/) ([MacTeX](https://www.tug.org/mactex/))。 - > 对于不同的发行版会有不同的包名其中主要包名有texlive(安同). texlive-full(debian系), texlive-binextra texlive-bin(arch系) mactex(mac) -3. 生成 PDF 和/或 HTML 文档 - > 可以用以下命令生成文档: - ```bash - make all # 生成PDF文档 - make html # 将 TeX 转换为 HTML - make clean # 删除生成的文件 - ``` +> 目录: +> * [0 准备工作](文档/0-准备工作) +> * [1 编写驱动](文档/1-编写驱动) +> * [2 驱动相关文件](文档/2-驱动相关文件) +> * [3 ioctl](文档/3-ioctl) +> * [4 系统调用](文档/4-系统调用) +> * [5 阻塞进程和线程](文档/5-阻塞进程和线程) +> * [6 内核模块的锁](文档/6-内核模块的锁) +> * [7 驱动与用户交互](文档/7-驱动与用户交互) +> * [8 调度与中断](文档/8-调度与中断) +> * [](文档/) ## 版权说明 diff --git a/assets/Manrope_variable.ttf b/assets/Manrope_variable.ttf deleted file mode 100644 index f41386f..0000000 Binary files a/assets/Manrope_variable.ttf and /dev/null differ diff --git a/contrib.tex b/contrib.tex deleted file mode 100644 index b8ec251..0000000 --- a/contrib.tex +++ /dev/null @@ -1,59 +0,0 @@ -Amit Dhingra, % -Andy Shevchenko, % -Arush Sharma, % <46960231+arushsharma24@users.noreply.github.com> -Benno Bielmeier, % <32938211+bbenno@users.noreply.github.com> -Bob Lee, % -Brad Baker, % -Che-Chia Chang, % -Cheng-Shian Yeh, % -Chih-En Lin, % -Chih-Hsuan Yang, % -Chih-Yu Chen, % <34228283+chihyu1206@users.noreply.github.com> -Ching-Hua (Vivian) Lin, % -Chin Yik Ming, % -cvvletter, % -Cyril Brulebois, % -Daniele Paolo Scarpazza, % <> -David Porter, % <> -demonsome, % -Dimo Velev, % <> -Ekang Monyet, % -Ethan Chan, % -Francois Audeon, % <> -Gilad Reti, % -heartofrain, % -Horst Schirmeier, % <> -Hsin-Hsiang Peng, % -Ignacio Martin, % <> -I-Hsin Cheng, % -Iûnn Kiàn-îng, % -Jian-Xing Wu, % -Johan Calle, % <43998967+jcallemc@users.noreply.github.com> -keytouch, % -Kohei Otsuka, % <13173186+rjhcnf@users.noreply.github.com> -Kuan-Wei Chiu, % -manbing, % -Marconi Jiang, % -mengxinayan, % <31788564+mengxinayan@users.noreply.github.com> -Meng-Zong Tsai, % -Peter Lin, % -Roman Lakeev, % <> -Sam Erickson, % -Shao-Tse Hung, % -Shih-Sheng Yang, % -Stacy Prowell, % -Steven Lung, % <1030steven@gmail.com> -Tristan Lelong, % -Tse-Wei Lin, % <20110901eric@outlook.com> -Tucker Polomik, % -Tyler Fanelli, % -VxTeemo, % -Wei-Hsin Yeh, % -Wei-Lun Tsai, % -Xatierlike Lee, % -Yen-Yu Chen, % -Yin-Chiuan Chen, % -Yi-Wei Lin, % -Yo-Jung Lin, % <0xff07@gmail.com> -Yu-Hsiang Tseng, % -YYGO. % diff --git a/html.cfg b/html.cfg deleted file mode 100644 index 0d239df..0000000 --- a/html.cfg +++ /dev/null @@ -1,91 +0,0 @@ -\Preamble{xhtml} - -\Configure{tableofcontents*}{chapter,section,subsection} - -\Css{html { - width: 100vw; - overflow-x: hidden; -}} - -\Css{@font-face { - font-family: Manrope; - src: url(Manrope_variable.ttf); -}} - -\Css{body { - max-width: 55rem; - box-sizing: border-box; - padding: 1rem; - margin: 0 auto; - overflow-x: hidden; - background-color: \#F4ECD8; - color: \#5B464B; - line-height: 1.5; -}} - -\Css{a { -color: \#0060DF; -}} - -\Css{p, a { -font-size: 1.2rem; -font-family: Manrope; -}} - -\Css{p + pre { -font-size: 1.1em; -}} - -\Css{div.author { - white-space: normal; -}} - -\Css{img.math { - height: 1rem; - vertical-align: top; -}} - -\Css{pre.fancyvrb, { - white-space: pre; -}} - -\Css{figure, .fancyvrb, .verbatim { - margin-inline: 0; - overflow-x: auto; -}} - -\Css{.ecrm-0500 { - font-size: 70\%; - font-style: italic; - color: gray; - width: 1.5rem; - display: inline-block; - -webkit-user-select: none; - -moz-user-select: none; - -o-user-select: none; - user-select: none; -}} - -\Css{.flushright:first-child { - position:absolute; - top: 10px; - right: 50px; -}} - -\Css{.right { - text-align: right; -}} - -\AtBeginDocument{% -\Configure{@HEAD}{\HCode{ - -
- View on GitHub - Download PDF document -

-
- \Hnewline}} -} - -\begin{document} -\EndPreamble diff --git a/lib/codeblock.tex b/lib/codeblock.tex deleted file mode 100644 index 692fa55..0000000 --- a/lib/codeblock.tex +++ /dev/null @@ -1,37 +0,0 @@ -\newminted[code]{c}{frame=single, - framesep=2mm, - baselinestretch=1, - fontsize=\footnotesize, - breaklines, - breakafter=d, - linenos -} - -\usemintedstyle{vs} - -\NewDocumentCommand{\samplec}{oom}{% - \IfNoValueTF{#1}% - {% - \inputminted[frame=single, framesep=2mm, baselinestretch=1, fontsize=\footnotesize, breaklines, breakafter=d, linenos]{c}{#3}% - }% - {% - \IfNoValueTF{#2}% - {% - \inputminted[frame=single, framesep=2mm, baselinestretch=1, fontsize=\footnotesize, breaklines, breakafter=d, firstline=#1, linenos]{c}{#3}% - }% - {% - \inputminted[frame=single, framesep=2mm, baselinestretch=1, fontsize=\footnotesize, breaklines, breakafter=d, firstline=#1, lastline=#2, linenos]{c}{#3}% - }% - }% -} - -\newminted[codebash]{bash}{frame=single, - framesep=2mm, - baselinestretch=1.2, - breaklines, - breakafter=d, - linenos -} - -\newmintinline[sh]{bash}{} -\newmintinline[cpp]{c}{} diff --git a/lib/kernelsrc.tex b/lib/kernelsrc.tex deleted file mode 100644 index 403e826..0000000 --- a/lib/kernelsrc.tex +++ /dev/null @@ -1,2 +0,0 @@ -\newcommand*{\src}[2][]{\href{https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/#2}% - {\ifthenelse{\equal{#1}{}}{#2}{#1}}} diff --git a/lkmpg.tex b/lkmpg.tex deleted file mode 100644 index fb78575..0000000 --- a/lkmpg.tex +++ /dev/null @@ -1,1894 +0,0 @@ -\documentclass[10pt, oneside]{book} -\usepackage[Bjornstrup]{fncychap} -\usepackage[utf8]{inputenc} -\usepackage[T1]{fontenc} -\usepackage{graphicx} -\usepackage{fancyhdr} -\usepackage{xparse} -\usepackage{ifthen} -\usepackage{pdfpages} -\usepackage{CJKutf8} - -% TikZ设置 -\usepackage{tikz} -\usetikzlibrary{shapes.geometric, arrows, shadows, decorations.text} -\tikzstyle{startstop} = [rectangle, rounded corners, minimum width=3cm, minimum height=1cm,text centered, draw=black, fill=red!30, drop shadow] -\tikzstyle{io} = [trapezium, trapezium left angle=70, trapezium right angle=110, minimum width=3cm, minimum height=1cm, text centered, draw=black, fill=blue!30] -\tikzstyle{process} = [rectangle, minimum width=3cm, minimum height=1cm, text centered, text width=3cm, draw=black, fill=orange!30] -\tikzstyle{decision} = [diamond, minimum width=1cm, minimum height=1cm, text centered, draw=black, fill=green!30] -\tikzstyle{arrow} = [thick,->,>=stealth] -\tikzstyle{line} = [draw, -latex'] - -% 代码包 -\usepackage{verbatim} -\usepackage{minted} -% 引用 -\usepackage{cite} -\usepackage[colorlinks,citecolor=green]{hyperref} -\usepackage{xcolor} -% 超链接 -\hypersetup{ - colorlinks, - linkcolor = {red!50!black}, - citecolor = {blue!50!black}, - urlcolor = {blue!80!black} -} - -\input{lib/codeblock} -\input{lib/kernelsrc} - -\renewcommand{\thesection}{\arabic{section}} - -\title{Linux内核模块的编程指南} -\begin{document} -\begin{CJK*}{UTF8}{gbsn} - -% 目录 -\maketitle -\pagestyle{empty} -\tableofcontents - -\section{引言} -\label{sec:引言} - -《Linux内核模块编程指南》是一本免费的书；你可以根据 \href{https://opensource.org/licenses/OSL-3.0}{开放软件许可证(Open Software License)} 3.0版的条款复制和/或修改它。 - -本书的发行是希望它会有用, 但没有任何担保, 甚至没有对适销性或特定用途的适用性的暗示担保。 - -作者鼓励广泛分发本书供个人或商业使用, 前提是上述版权声明保持不变, 并且该方法符合\href{https://opensource.org/licenses/OSL-3.0}{开放软件许可证(Open Software License)}的规定。总之, 你可以免费复制和分发本书, 也可以赢利。以任何媒介、物理或电子形式复制本书, 无需获得作者的明确许可。 - -本文档的衍生作品和翻译必须置于开放软件许可证下, 并且原始版权声明必须保持不变。如果你为本书贡献了新材料, 则必须为你的修订提供材料和源代码。请直接向文档维护者Jim Huang提供修订和更新。这将允许合并更新, 并为Linux社区提供一致的修订。 - -如果你以商业方式出版或分发本书, 作者和\href{https://tldp.org/}{Linux文档项目(LDP)}将非常感谢你的捐赠、版税和/或印刷本。以这种方式贡献表明你支持自由软件和LDP。如果你有任何问题或意见, 请联系上述地址。 - -\subsection{作者} -\label{sec:作者} - -《Linux内核模块编程指南》最初由Ori Pomerantz for Linux v2.2编写。随着Linux内核的发展, Ori维护文档的可用性降低了。因此, Peter Jay Salzman承担了维护者的角色, 并更新了Linuxv2.4指南。在跟踪Linux v2.6中的开发时, Peter也受到了类似的限制, 导致Michael Burian加入为共同维护者, 以使该指南与Linux v2.6同步。Bob Mottram通过更新Linux v3.8和更高版本的示例对该指南做出了贡献。Jim Huang随后承担了更新最新Linux版本(v5.0及更高版本)指南的任务, 并修订LaTeX文档。 - -\subsection{致谢} -\label{sec:致谢} - -以下人员为本书提供了一些更正与良好的建议: - -\begin{flushleft} -\input{contrib} -\end{flushleft} - -\subsection{什么是内核模块?} -\label{sec:kernelmod} - -参与Linux内核模块开发需要扎实的C编程语言基础和创建用于进程执行的传统程序的丰富经验。这一追求涉及到一个领域, 如果处理不当, 一个未受限制的指针可能会导致整个文件系统的崩溃, 导致系统必须重启。 - -Linux 内核模块的确切定义是: 能够根据需要在内核中动态加载和卸载的代码段。 -这些模块增强了内核功能, 而无需重新启动系统。 -一个值得注意的例子是设备驱动程序模块, 它促进了内核与链接到系统的硬件组件的交互。 -在没有模块的情况下, 主流的方法倾向于使用单内核( Monolithic Kernel 也可以称之为宏内核 Macrokernel ), 需要将新功能直接集成到内核镜像中。这种方法会导致内核变得更大, 并在需要新增功能时, 必须重新构建内核并进行系统重启。 - -译者注: 单内核( Monolithic Kernel) 有时候也被称之为宏内核(Macrokernel), 与其对应的另一种内核形式是微内核, Linux内核是微内核和内核的混合产物 - -\subsection{内核模块包} -\label{sec:packages} - -Linux发行版在一个包中提供了命令 \sh|modprobe|, \sh|insmod| 和 \sh|depmod|。 - -在安同上: -\begin{codebash} -sudo oma install gcc kmod -\end{codebash} - -在 Debian 与其衍生发行版(乌班图ubuntu, 深度deebin, kali)上: -\begin{codebash} -sudo apt-get install build-essential kmod -\end{codebash} - -在 Arch Linux系上: -\begin{codebash} -sudo pacman -S gcc kmod -\end{codebash} - -\subsection{我的内核中有哪些模块?} -\label{sec:modutils} - -要发现当前内核中已经加载了哪些模块可以使用命令 \sh|lsmod|. -\begin{codebash} -sudo lsmod -\end{codebash} - -模块存储在文件 \verb|/proc/modules| 中, 因此你也可以使用以下命令查看它们: -\begin{codebash} -sudo cat /proc/modules -\end{codebash} - -这可能是一个很长的列表, 可以使用grep命令搜索某类模块, 比如使用下述命令搜索网络模块 -\begin{codebash} -sudo lsmod | grep net -\end{codebash} - -\subsection{是否需要下载和编译内核?} -\label{sec:buildkernel} - 本指南并没有对此有强制要求。但建议本指南的示例使用虚拟机运行, 从而减少可能对系统造成的任何风险 - -\subsection{开始之前} -\label{sec:preparation} - 在深入研究代码之前, 需要注意某些事项。每个人的主机都有所不同, 所以在不同的内核与发行版之间都可能存在一些差异, 成功编译和加载首个 "hello world" 程序有时可能会是一个挑战。 克服最初的障碍是一个令人欣慰的过程, 它会为你后续的努力铺平道路。 - -\begin{enumerate} - \item Modversioning. - 如果引导不同的内核, 则为一个内核编译的模块将不会加载, 除非在内核中启用了 \cpp|CONFIG_MODVERSIONS| 本指南稍后将讨论模块版本化问题。在讨论模块版本控制之前, 如果在启用了 modversioning 的情况下运行内核, 则本指南中的示例可能无法正常工作。然而, 大多数Linux发行版内核都启用了 modversioning 。如果由于版本控制错误而在加载模块时出现问题, 请考虑在关闭 modversioning 的情况下编译内核。 - - \item 使用 X Window System. - 强烈建议使用控制台(终端)中获取、编译、运行本指南中讨论的所有示例, 不建议使用可视化窗口运行 - - 模块不能像 \cpp|printf()| 那样直接打印到屏幕上, 但它们可以记录最终显示在屏幕上的信息和警告, 特别是在控制台中。如果从 \sh|xTER| 加载模块, 则信息和警告将被记录在systemd日志中。只有查询 \sh|journalctl|才能看到这些日志。 有关详细信息, 请看 \ref{sec:helloworld} 。为了即时访问此信息, 建议从控制台执行所有任务。 - - \item SecureBoot. - 许多现代计算机都预先配置了UEFI SecureBoot, 这是一个基本的安全标准, 确保仅通过原始设备制造商认可的可信软件引导。某些Linux发行版甚至附带配置为支持SecureBoot的默认Linux内核。在这些情况下, 内核模块需要一个签名的安全密钥。 - - 如果在启动"hello world"模块时出现错误信息: ``\emph{ERROR: could not insert module(错误:无法插入模块)}''。如果此消息 \emph{Lockdown: insmod: unsigned module loading is restricted; see man kernel lockdown.7(未签名的模块的装载限制, 请参阅 man kernel lockdown.7 )} 出现在 \sh|dmesg| 输出, 最简单的方法是从主机的引导菜单中禁用UEFI SecureBoot。当然, 另一种方法涉及复杂的过程, 如生成密钥、系统密钥安装和模块签名, 以实现功能。然而, 这种复杂的过程不太适合初学者。如果有兴趣, 可以探索和遵循\href{https://wiki.debian.org/SecureBoot}{SecureBoot}的更详细步骤。 -\end{enumerate} - -\section{开始(头部)} -\label{sec:headers} - 在构建任何东西之前, 必须安装内核的头文件。 - - 对于几乎所有的发行版都可以使用如下命令来确定是否已有内核头文件 -\begin{codebash} -ls /lib/modules/$(uname -r)/build -\end{codebash} - - 如果上述命令返回不为空则代表存在相关内核头文件, 其他情况需要从包管理器中手动下载, 内核头文件的包名在Debian系或Arch系中名称一般是 linux-headers、linux-headers-(内核版本号)-其他, 而在红帽系中一般名称是 kernel-devel和kernel-headers - -\section{示例} -\label{sec:examples} - 本文档中的所有示例都位于 \verb|examples| 子目录中。 - - 如果发生编译错误, 可能是由于正在使用较新的内核版本, 或者可能需要安装相应的内核头文件。 - -\section{Hello World} -\label{sec:helloworld} -\subsection{最简单的模块} -\label{sec:org2d3e245} - 大多数人开始他们的编程旅程通常从 \emph{hello world} 示例的某种变体开始。偏离这一传统的人目前尚未可知会产生什么结果, 但坚持这一传统似乎是明智的。 学习过程将从一系列hello world程序开始, 这些程序说明了编写内核模块的各个基本方面。 - - 接下来介绍的可能是最简单的模块。 - - 创建测试目录: -\begin{codebash} -mkdir -p ~/develop/kernel/hello-1 -cd ~/develop/kernel/hello-1 -\end{codebash} - - 将下述代码粘贴到你喜爱的编辑器中, 并将其命名为 \verb|hello-1.c|: - -\samplec{examples/hello-1.c} - - 现在你需要一个 \verb|Makefile| 。如果复制并粘贴此内容, 请将缩进更改为使用 \textit{制表符(tabs)}, 而不是空格。 - -\begin{code} -obj-m += hello-1.o - -PWD := $(CURDIR) - -all: - make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules - -clean: - make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean -\end{code} - - 在 \verb|Makefile| 中, \verb|$(CURDIR)| 可以设置为当前工作目录的绝对路径名(在处理所有 \verb|-C| 选项后, 如果有)。请参阅 \href{https://www.gnu.org/software/make/manual/make.html}{GNU make manual} 中有关 \verb|CURDIR| 的更多信息。 - - 后续直接运行make即可 - -\begin{codebash} -make -\end{codebash} - - 如果在Makefile中没有 \verb|PWD := $(CURDIR)| 这样的语句, 那么使用\verb|sudo make| 可能无法正确编译。这是因为一些环境变量受到安全策略的限制, 不能被继承。默认的安全策略是 \verb|sudoers| 。在 \verb|sudoers| 安全策略中, 默认启用了 \verb|env_reset| , 这会限制环境变量的使用。具体来说, 路径变量不会从用户环境中保留, 而是被设置为默认值(更多信息请参考\href{https://www.sudo.ws/docs/man/sudoers.man/}{sudoers 手册})。你可以通过以下方式查看环境变量的设置: - -\begin{verbatim} -$ sudo -s -# sudo -V -\end{verbatim} - - 下面以一个简单的 Makefile 为例, 演示上述问题。 - -\begin{code} -all: - echo $(PWD) -\end{code} - - 我们可以使用 \verb|-p| 标志从Makefile中打印出环境变量值。 - -\begin{verbatim} -$ make -p | grep PWD -PWD = /home/ubuntu/temp -OLDPWD = /home/ubuntu - echo $(PWD) -\end{verbatim} - - \verb|PWD| 变量不会与 \verb|sudo| 一起继承。 - -\begin{verbatim} -$ sudo make -p | grep PWD - echo $(PWD) -\end{verbatim} - - 有三种方法可以解决这个问题。 - -\begin{enumerate} - \item { - 可以使用 \verb|-E| 标志临时保留它们。 - - \begin{codebash} - $ sudo -E make -p | grep PWD - PWD = /home/ubuntu/temp - OLDPWD = /home/ubuntu - echo $(PWD) - \end{codebash} - } - - \item { - 可以通过执行\verb|visudo|命令, 编辑\verb|/etc/sudoers|来禁用\verb|env_reset|(环境重置)。 - - \begin{code} - ## sudoers 文件. - ## - ... - Defaults env_reset - ## 将env_reset更改为!env_reset, 其他环境变量不做更改 - \end{code} - - 然后分别执行 \verb|env|和\verb|sudo env| - - \begin{codebash} - # 禁用 env_reset - echo "user:" > non-env_reset.log; env >> non-env_reset.log - echo "root:" >> non-env_reset.log; sudo env >> non-env_reset.log - # 启用 the env_reset - echo "user:" > env_reset.log; env >> env_reset.log - echo "root:" >> env_reset.log; sudo env >> env_reset.log - \end{codebash} - - 可以查看上述日志发现 \verb|env_reset| 和 \verb|!env_reset|的差异 - } - - \item {可以通过将环境变量附加到\verb|/etc/sudoers|中的\verb|env_keep|来保留环境变量 - - \begin{code} - Defaults env_keep += "PWD" - \end{code} - - 应用上述更改后, 可以通过以下方式检查环境变量设置: - - \begin{verbatim} - $ sudo -s - # sudo -V - \end{verbatim} - } -\end{enumerate} - - 如果一切顺利, 你应该会发现你有一个已编译的\verb|hello-1.ko|模块。你可以使用以下命令查找有关它的信息: -\begin{codebash} -modinfo hello-1.ko -\end{codebash} - - 使用此命令: -\begin{codebash} -sudo lsmod | grep hello -\end{codebash} - - 应不返回任何内容。但尝试接下来的命令加载新模块: -\begin{codebash} -sudo insmod hello-1.ko -\end{codebash} - - 载入模块时中划线(hello-1)将会被替换成下划线(hello\_1), 因此当你再次尝试时: -\begin{codebash} -sudo lsmod | grep hello -\end{codebash} - - 你应该可以看到已加载的模块。可以使用以下命令再次移除它(请注意, 中划线已被下划线替换): -\begin{codebash} -sudo rmmod hello_1 -\end{codebash} - - 要查看日志中刚刚发生的情况, 请执行以下操作: -\begin{codebash} -sudo journalctl --since "1 hour ago" | grep kernel -\end{codebash} - - 现在你已经了解了创建、编译、安装和删除模块的基础知识。现在, 更多地描述该模块的工作原理。 - - 内核模块必须至少有两个函数: 一个名为 \cpp|init_module()| 的 "init"(初始化) 函数, 当模块被插入内核时调用；另一个名为主模块的 "cleanup"(清理) 函数, 在将其从内核中删除之前调用。实际上, 从内核2.3.13开始, 情况发生了变化。现在, 你可以为模块的开始和结束函数使用任何名称, 你将在第\ref{hello_n_goodbye}节中学习如何做到这一点。事实上, 新方法是首选方法。然而, 许多人仍然使用 \cpp|init_module()| 和 \cpp|cleanup_module()| 作为他们的开始和结束函数。 - - 通常, \cpp|init_module()| 要么向内核注册某个对象的处理程序, 要么用自己的代码替换其中一个内核函数(通常是执行某些操作的代码, 然后调用原始函数)。\cpp|cleanup_module()| 函数的作用是撤消 \cpp|init_module()| 所做的任何操作, 因此可以安全地卸载该模块。 - - 最后, 每个内核模块都需要包含\verb||。我们只需要为 \cpp|pr_alert()| 日志级别的宏扩展包含\verb||, 你将在第\ref{sec:printk}节中了解这一点。 - -\begin{enumerate} - \item 关于编码风格。 - 对任何开始内核编程的人来说都不容易被注意到的事情是, 代码中的缩进应该使用\textbf{制表符(tabs)}, 而不是空格。它是内核的编码约定之一。你可能不喜欢它, 但如果你想要向上游提交补丁, 则需要习惯它。并且内核中的注释无论是单行还是多行都习惯使用 /**/ 的方式而非 // - - \item 介绍打印(print)宏。 - \label{sec:printk} - 一开始是 \cpp|printk| , 后面通常是优先级, 如\cpp|KERN_INFO| 或者 \cpp|KERN_DEBUG|。在较新的内核也可以使用一组打印宏(如\cpp|pr_info| 和 \cpp|pr_debug|)以缩写形式表示。这只是省去了一些无意义的键盘敲击, 看起来更加整洁。它们可以在\src{include/linux/printk.h}中找到。请花时间阅读可用的优先级宏(更多信息请参考\href{https://www.kernel.org/doc/html/latest/translations/zh_CN/core-api/printk-basics.html}{中文版 printk 手册}/\href{https://www.kernel.org/doc/html/latest/core-api/printk-basics.html}{英文版 printk 手册})。 - - \item 关于编译。 - 内核模块的编译需要与常规用户空间应用程序稍有不同。以前的内核版本要求我们非常关心这些设置, 这些设置通常存储在Makefiles中。尽管分层组织, 但许多冗余设置积累在子级Makefiles中, 使它们变得很大, 很难维护。幸运的是, 有一种新的方法来完成这些事情, 称为kbuild, 并且外部可加载模块的构建过程现在完全集成到标准内核构建机制中。要了解有关如何编译不属于官方内核的模块(如本指南中的所有示例)的更多信息, 请参阅文件\src{Documentation/kbuild/modules.rst}。 - - 有关内核模块的Makefiles的其他详细信息, 请参阅\src{Documentation/kbuild/makefiles.rst}。在开始修改Makefile之前, 请务必阅读此文件和相关文件。它可能会为你节省大量工作。 - -\begin{quote} - 这里是读者的另一个练习。看到\cpp|init_module()|中return语句上方的注释了吗？将返回值更改为负值, 重新编译并再次加载模块。发生了什么？ -\end{quote} -\end{enumerate} - -\subsection{你好, 再见} -\label{hello_n_goodbye} - 在早期的内核版本中, 你必须使用 \cpp|init_module| 和 \cpp|cleanup_module|函数, 就像在第一个hello world示例中一样, 但现在你可以通过使用\cpp|module_init|和 \cpp|module_exit|宏来命名这些函数。这些宏在 \src{include/linux/module.h} 中定义。唯一的要求是必须在调用这些宏之前定义init和cleanup函数, 否则将出现编译错误。下面是该技术的一个示例: - -\samplec{examples/hello-2.c} - - 现在我们有两个真正的内核模块。添加另一个模块非常简单: - -\begin{code} -obj-m += hello-1.o -obj-m += hello-2.o - -PWD := $(CURDIR) - -all: - make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules - -clean: - make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean -\end{code} - - 现在来看一个现实的示例 \src{drivers/char/Makefile} 。如你所见, 有些东西已经被硬编码到内核中(\verb|obj-y|), 但所有这些\verb|obj-m|都到哪里去了？熟悉shell脚本的人将很容易发现它们。对于那些不熟悉的人来说, 你在各处看到的 obj-\$(CONFIG\_FOO) 条目会根据 CONFIG\_FOO 变量是设置为 y 还是 m, 展开为\verb|obj-y| 或 \verb|obj-m|。顺便提一下, 这些正是你在 Linux 内核源代码树的顶级目录下使用 make menuconfig 或类似命令时, 在 .config 文件中设置的那种变量。 - -\subsection{ \_\_init 和 \_\_exit 宏} -\label{init_n_exit} - \cpp|__init|宏会导致在初始化函数为内置驱动程序(但不是可加载模块)完成后丢弃初始化函数并释放其内存。如果你思考一下 初始化 函数何时被调用就会发现这是非常合理的操作, 因为内置模块不需要再次加载, 而可加载的模块则需要。 - - 还有一个\cpp|__initdata|, 其工作方式类似于\cpp|__init|, 但用于初始化变量而不是函数。 - - \cpp|__exit| 宏会在将模块内置到内核时也会被省略, 与 \cpp|__init| 类似, 对可加载模块没有影响。考虑到 退出 函数的作用这种做法也是完全合理的。 - - 这些宏在\src{include/linux/init.h}中定义, 用于释放内核内存。当引导内核并看到类似"释放未使用的内核内存: 236k已释放"的内容时, 这正是内核正在释放的内容。 - -\samplec{examples/hello-3.c} - -\subsection{许可(Licensing)和模块文档} -\label{modlicense} - 老实说, 谁加载甚至关心专有模块？如果你这样做, 你可能会看到这样的情况: -\begin{verbatim} -$ sudo insmod xxxxxx.ko -loading out-of-tree module taints kernel. -module license 'unspecified' taints kernel. -\end{verbatim} - - 你可以使用几个宏来指示模块的许可证。常见示例有"GPL"、"GPL v2"、"GPL和附加权限(GPL and additional rights)"、"Dual BSD/GPL", "Dual MIT/GPL""Dual MPL/GPL"和"Proprietary"。它们在\src{include/linux/module.h}中定义。 - - 要引用你正在使用的许可证, 可以使用名为\cpp|MODULE_LICENSE|的宏。下面的示例中说明了该宏和几个描述该模块的其他宏。 - -\samplec{examples/hello-4.c} - -\subsection{将命令行参数传递到模块} -\label{modparam} - 模块可以采用命令行参数, 但不能使用你可能习惯的argc/argv。 - - 要允许将参数传递给模块, 请声明将采用命令行参数值的变量作为全局变量, 然后使用 \cpp|module_param()| 宏(在\src{include/linux/moduleparam.h}中定义)来设置机制。在运行时, \sh|insmod| 将使用给定的任何命令行参数填充变量, 如 \sh|insmod mymodule.ko myvariable=5| 。为了清楚起见, 变量声明和宏应该放在模块的开头。这块解释的很糟糕, 还是无法理解可以试着查看实例代码。 - -\cpp|module_param()|宏接受3个参数: 变量的名称、类型和sysfs中相应文件的权限。整数类型可以像平常一样有符号, 也可以无符号。如果要使用整数数组或字符串数组, 请使用 \cpp|module_param_array()| 和 \cpp|module_param_string()|。 - -\begin{code} -int myint = 3; -module_param(myint, int, 0); -\end{code} - - 数组也得到了支持, 但与过去相比, 现在的处理方式有所不同。为了跟踪参数数量, 你需要将一个指向计数变量的指针作为第三个参数传递。你也可以选择忽略计数并传递 \cpp|NULL|。这里我们展示了两种可能性: - -\begin{code} -int myintarray[2]; -module_param_array(myintarray, int, NULL, 0); /* 不需求计数器 */ - -short myshortarray[4]; -int count; -module_param_array(myshortarray, short, &count, 0); /* 将计数器的值传给count */ -\end{code} - - 这种用法的一个好处是可以设置模块变量的默认值, 如端口或 IO 地址。如果变量包含默认值, 则执行自动检测(在其他地方解释)。否则, 保留当前值。这将在后面详细说明。 - - 最后, 有一个宏函数\cpp|MODULE_PARM_DESC()|, 用于记录模块可以接受的参数。它接受两个参数: 变量名和描述该变量的自由格式字符串。 - -\samplec{examples/hello-5.c} - - 推荐使用下述方法测试参数传递代码: -\begin{verbatim} -$ sudo insmod hello-5.ko mystring="bebop" myintarray=-1 -$ sudo dmesg -t | tail -7 -myshort is a short integer: 1 -myint is an integer: 420 -mylong is a long integer: 9999 -mystring is a string: bebop -myintarray[0] = -1 -myintarray[1] = 420 -got 1 arguments for myintarray. - -$ sudo rmmod hello-5 -$ sudo dmesg -t | tail -1 -Goodbye, world 5 - -$ sudo insmod hello-5.ko mystring="supercalifragilisticexpialidocious" myintarray=-1,-1 -$ sudo dmesg -t | tail -7 -myshort is a short integer: 1 -myint is an integer: 420 -mylong is a long integer: 9999 -mystring is a string: supercalifragilisticexpialidocious -myintarray[0] = -1 -myintarray[1] = -1 -got 2 arguments for myintarray. - -$ sudo rmmod hello-5 -$ sudo dmesg -t | tail -1 -Goodbye, world 5 - -$ sudo insmod hello-5.ko mylong=hello -insmod: ERROR: could not insert module hello-5.ko: Invalid parameters -\end{verbatim} - -\subsection{跨多文件的模块} -\label{modfiles} - 有时将内核模块划分为几个源文件是有意义的。 - 下面是这样一个内核模块的示例。 -\samplec{examples/start.c} - - 下一个文件: -\samplec{examples/stop.c} - - 最后, 生成文件: - -\begin{code} -obj-m += hello-1.o -obj-m += hello-2.o -obj-m += hello-3.o -obj-m += hello-4.o -obj-m += hello-5.o -obj-m += startstop.o -startstop-objs := start.o stop.o - -PWD := $(CURDIR) - -all: - make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules - -clean: - make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean -\end{code} - - 这是我们迄今为止看到的所有示例的完整 Makefile。前五行没什么特别的, 但对于最后一个示例, 我们将需要两行。首先, 我们为我们的组合模块发明一个对象名称, 其次我们告诉 \sh|make| 哪些对象文件是该模块的一部分。 - -\subsection{为预编译内核构建模块} -\label{precompiled} - 我们强烈建议你重新编译内核, 以便你可以启用许多有用的调试功能, 例如强制模块卸载(\cpp|MODULE_FORCE_UNLOAD|): 当启用此选项时, 你可以通过\sh|sudo rmmod -f module|命令强制内核卸载模块, 即使它认为模块不安全。在模块开发过程中, 此选项可以节省大量时间和多次重新启动。如果不想重新编译内核, 则应该考虑在虚拟机上的测试发行版中运行这些示例。如果你搞坏了什么, 可以快速重新启动或恢复虚拟机(VM)。 - - 在许多情况下, 你可能希望将模块加载到预编译的运行内核中, 例如常见Linux发行版附带的内核, 或者你过去编译过的内核。在某些情况下, 你可能需要编译模块并将其插入到不允许重新编译的正在运行的内核中, 或者在不希望重新启动的机器上。如果你想不出一种情况会迫使你为预编译内核使用模块, 那么你可能想跳过本节剩下的内容, 并将本节的其余部分视为一个大脚注。 - - 如果你只是安装内核源代码树(kernel source tree), 请使用它来编译内核模块, 然后尝试将模块插入内核, 在大多数情况下, 你将获得如下错误: - -\begin{verbatim} -insmod: ERROR: could not insert module poet.ko: Invalid module format -报错翻译: insmod: 错误:无法插入poet.ko模块: 无效的模块格式 -\end{verbatim} - - 一些隐秘信息被记录到systemd日志中: - -\begin{verbatim} -kernel: poet: disagrees about version of symbol module_layout -报错翻译: kernel: poet: 对 module_layout 的版本符号存在分歧 -\end{verbatim} - - 换句话说, 内核拒绝接受模块, 因为版本信息(更准确的翻译应该是 \textit{版本魔术(version magic)}, 在这里版本信息更有助于理解, 后续所有version magic的翻译都会翻译成版本信息, 请参阅\src{include/linux/vermagic.h})不匹配。顺便说一句, 版本信息以静态字符串的形式存储在模块对象中, 从\cpp|vermagic:|开始。当版本信息链接到\verb|kernel/module.o|文件时, 它会插入到模块中。要检查存储在给定模块中的版本信息和其他字符串, 请发出命令sh|modinfo module.ko|: - -\begin{verbatim} -$ modinfo hello-4.ko -description: A sample driver -author: LKMPG -license: GPL -srcversion: B2AA7FBFCC2C39AED665382 -depends: -retpoline: Y -name: hello_4 -vermagic: 5.4.0-70-generic SMP mod_unload modversions -\end{verbatim} - - 为了克服这个问题, 我们可以使用\verb|--force-vermagic|选项, 但这种解决方案可能是不安全的, 并且在生产环境中是不可接受的。因此, 我们希望在与构建预编译内核的环境相同的环境中编译模块。如何做到这一点, 是本章其余部分的主题。 - - 首先, 确保有一个内核源代码树可用, 其版本与当前内核完全相同。然后, 找到用于编译预编译内核的配置文件。这通常在\verb|/boot|目录下, 文件名类似于 \verb|config-5.14.x|。你可能只需将其复制到内核源代码树中: 执行命令 \sh|cp /boot/config-`uname -r` .config| 。 - - 观察之前的版本信息, 即使两个配置文件完全相同, 版本信息还是可能会出现一些差异阻止模块插入到内核中。这种差异是由于对某些发行版修改了Makefile中定义的版本信息所致。查看你的内核源码根目录下的Makefile, 确保指定的版本信息与当前内核使用的完全匹配。发行版的\verb|Makefile|是类似如下格式: - -\begin{verbatim} -VERSION = 5 -PATCHLEVEL = 14 -SUBLEVEL = 0 -EXTRAVERSION = -rc2 -\end{verbatim} - - 假设出现上述情况时, 我们需要将\verb|Makefile| 中的 \textbf{EXTRAVERSION} 的值配置为 \textbf{-rc2}。可以使用如下命令保留编译内核的makefile的备份。 - -\begin{codebash} -cp /lib/modules/`uname -r`/build/Makefile linux-`uname -r` -\end{codebash} - \sh|linux-`uname -r`| 是你试图构建的linux内核源代码, 可以之间在命令行中执行 \sh|`uname -r`| 查看返回值。 - - 最后, 请运行make来更新配置、头文件: - -\begin{verbatim} -$ make - SYNC include/config/auto.conf.cmd - HOSTCC scripts/basic/fixdep - HOSTCC scripts/kconfig/conf.o - HOSTCC scripts/kconfig/confdata.o - HOSTCC scripts/kconfig/expr.o - LEX scripts/kconfig/lexer.lex.c - YACC scripts/kconfig/parser.tab.[ch] - HOSTCC scripts/kconfig/preprocess.o - HOSTCC scripts/kconfig/symbol.o - HOSTCC scripts/kconfig/util.o - HOSTCC scripts/kconfig/lexer.lex.o - HOSTCC scripts/kconfig/parser.tab.o - HOSTLD scripts/kconfig/conf -\end{verbatim} - - 如果你不想编译完整的内核, 在SPLIT行之后中断构建 (CTRL-C) 即可, 后续返回到模块的目录并编译模块即可: 它将完全根据你当前的内核设置构建, 并且它将在没有任何错误的情况下加载。 - -\section{准备工作} -\subsection{模块开始和结束方式} -\label{sec:module_init_exit} - - 典型的程序以 \cpp|main()| 函数开始, 执行一系列指令, 并在完成这些指令后终止。然而内核模块遵循模式有所不同。模块总是以\cpp|init_module|函数或\cpp|module_init|调用指定的函数开头。该函数是模块的入口, 会通知内核模块的功能, 并在必要时让内核做好使用模块功能的准备。完成这些任务后, 入口函数返回, 模块将保持不活动状态, 直到内核使用其代码。 - - 所有模块都通过 \cpp|cleanup_module|函数 或 \cpp|module_exit| 调用指定的函数来结束。用作模块的退出功能, 通过注销以前注册的功能来逆转入口函数操作。 - - 每个模块都必须具有进入和退出功能。虽然有多种方法来定义这些函数, 但通常使用术语"进入函数(entry function)"和"退出函数(exit function)"。它们有时可能被称为\cpp|init_module| 和 \cpp|cleanup_module| 这两个模块的含义是相同的。 - -\subsection{模块可用的功能} -\label{sec:avail_func} - 程序员经常使用不是自己定义的函数。这方面的一个常见的例子是 \cpp|printf()|。在使用标准C库libc提供的这些库函数实际上直到链接阶段才会进入你的程序, 这确保代码(例如 \cpp|printf()|的代码)可用, 并将调用指令指向那段代码。 - - 内核模块在这里也有所不同。在"Hello World"示例中, 你可能注意到我们使用了函数\cpp|pr_info()|, 但没有包括标准I/O库。这是因为模块是对象文件, 其符号在运行\sh|insmod| 或 \sh|modprobe|时得到解析。符号的定义来自内核本身；你只能使用内核提供的外部函数。如果你对内核已导出的符号感兴趣, 可以查看\verb|/proc/kallsyms|。 - - 需要记住的一点是库函数和系统调用之间的区别。库函数是更上层的, 完全在用户空间中运行, 并为程序员提供了一个更方便的接口, 以实现真正的工作系统调用。 -系统调用代表用户在内核模式下运行, 并由内核本身提供。库函数\cpp|printf()|可能看起来像一个非常通用的打印函数, 但它真正做的只是将数据格式化为字符串, 并使用底层系统调用\cpp|write()|写入字符串数据, 然后将数据发送到标准输出。 - - 可以使用下述方法看看\cpp|printf()|都进行了那些系统调用。编译以下程序: - -\begin{code} -#include - -int main(void) -{ - printf("hello"); - return 0; -} -\end{code} - - 使用 \sh|gcc -Wall -o hello hello.c|。使用 \sh|strace ./hello| 运行可执行文件。你看到的每一行都对应于一个系统调用。 -\href{https://strace.io/}{strace} 是一个非常实用的程序, 它可以告诉你一个程序正在进行的系统调用的详细信息, 包括调用的是哪个系统函数、其参数是什么以及它返回了什么。 -这是一个极其宝贵的工具, 用来了解诸如程序试图访问哪些文件之类的问题。在输出的最后, 你会看到像 \cpp|write(1, "hello", 5hello)| 这样的一行。这就是 \cpp|printf()| 函数背后的真实系统调用。你可能不熟悉 \cpp|write| , 因为大多数人会使用库函数来进行文件 I/O (如 \cpp|fopen|, \cpp|fputs|, \cpp|fclose|)。 -如果想要了解更详细的信息可以查看 \sh|man 2 write|。第二部分的手册专门讨论系统调用(如 \cpp|kill()| 和 \cpp|read()|), 而第三部分的手册则专门讨论库调用, 你可能会更熟悉这部分(如 \cpp|cosh()| 和 \cpp|random()|)。 - - 你甚至可以编写模块来替换内核的系统调用, 我们很快就会这样做。这种操作常被骇客用于制作后门或木马程序, 但你可以编写自己的模块来做无害的事情, 比如每当有人试图删除你系统上的文件时, 让内核输出"哎呀！你干～嘛？" - -\subsection{用户空间vs内核空间} -\label{sec:user_kernl_space} - 内核主要管理对资源的访问, 无论是显卡、硬盘还是内存。程序经常争夺相同的资源。例如, 在保存文档时, updatedb可能会开始更新locate数据库。vim等编辑器中的会话和updatedb等进程可以同时利用硬盘。内核的作用是维护秩序, 确保用户不会随意访问资源。 - - 为了管理这些资源, CPU 在不同模式下运行, 每个模式都提供不同级别的系统控制。例如, 英特尔的80386架构就具有四种这样的模式, 称为环。然而, Unix仅使用其中两个环: 最高环(环0, 也称为"内核模式", 其中允许所有操作)和最低环, 称为"用户模式"。 - - 回顾关于库函数与系统调用的讨论。通常会在用户模式下使用库函数。库函数调用一个或多个系统调用, 并且这些系统调用以库函数的名义执行, 但在内核模式下执行, 因为它们是内核本身的一部分。一旦系统调用完成其任务, 它将返回, 并将执行权转交回用户模式。 - -\subsection{命名空间} -\label{sec:namespace} - 当你在编写一个小规模项目时, 使用通俗易懂的变量名通常是为了增加程序的可读性。但如果参与一个多人维护的庞大项目, 你的全局变量会和其他人的全局变量共存, 可能会出现全局变量名冲突的情况。当一个程序拥有大量全局变量且这些变量名不足以准确描述其用途时, 就会出现命名空间污染。在大型团队项目中, 在确保能记住保留的名称的同时, 需要找到一种制定方案, 以便为变量名和符号命名保持唯一性。 - - 在编写内核代码时, 即使是最小的模块也会链接到整个内核, 因此需要避免命名空间污染这个问题。处理此问题的最佳方法是将所有变量声明为静态, 并使用一个精准不会重复的前缀。按照惯例, 所有内核前缀都是小写的。如果你不想将所有内容都声明为静态, 另一个方法是声明符号表并将其注册到内核。我们稍后将讨论这个问题。 - - 文件 \verb|/proc/kallsyms|包含了内核所知道的所有符号, 因此这些符号对你的模块来说是可访问的, 因为它们共享了内核的代码空间。 - -\subsection{代码空间} -\label{sec:codespace} - 内存管理是一个非常复杂的主题, O'Reilly 出版的 \href{https://www.oreilly.com/library/view/understanding-the-linux/0596005652/}{Understanding The Linux Kernel(理解 Linux 内核)}一书中大部分内容都专注于内存管理！我们的目标不是成为内存管理方面的专家, 但我们确实需要掌握一些基本知识, 才能开始着手编写实际的模块。 - - 如果你没有深入思考过段错误(segfault)的真正含义, 你可能会惊讶地发现指针并不真正指向内存位置——至少不是真实的内存位置。当一个进程被创建时, 内核会划分一部分真实的物理内存并分配给该进程, 用于其执行代码、变量、栈、堆以及计算机科学家所熟知的其他内容。这部分内存从0x00000000开始, 延伸到所需的任何地址。由于任何两个进程的内存空间不会重叠, 任何可以访问某个内存地址(比如0xbffff978)的进程, 实际上访问的是物理内存中的不同位置！这些进程实际上访问的是名为0xbffff978的索引, 该索引指向为该特定进程预留的内存区域中的某个偏移量。大多数情况下, 像我们的"Hello, World"程序这样的进程不能访问其他进程的空间, 我们稍后会讨论一些可以做到这一点的方法。 - - 内核也有自己的内存空间。由于模块是可以在内核中动态插入和删除的代码(与半独立对象相反), 因此它共享内核的代码空间, 而不是拥有自己的代码空间。因此, 如果模块段出错, 则内核段出错。如果你因为一个"边界错误(off-by-one)"开始覆写数据, 那么你就是在破坏内核数据(或代码)。这种情况比听起来的还要危险, 所以尽量小心处理。 - -译者注: "半独立"强调的是既有独立操作的能力, 同时又不完全脱离外部控制或支持的状态, 内核模块直接运行在内核空间, 与内核共享相同的内存和执行环境, 而半独立的对象通常在用户空间运行, 拥有自己独立的内存和资源管理, 这使得它们在出现错误时不会直接影响到内核的稳定性。 - - 应当注意, 上述讨论适用于任何使用单块式内核(monolithic kernel)的操作系统。这个概念与"将所有模块构建到内核中"略有不同, 尽管底层原理类似。相反, 在微内核模块会分配自己的代码空间。微内核的著名的例子有\href{https://www.gnu.org/software/hurd/}{GNU Hurd}和谷歌Fuchsia的\href{https://fuchsia.dev/fuchsia-src/concepts/kernel}{锆石内核(Zircon kernel)}。 - -\subsection{设备驱动} -\label{sec:device_drivers} - 有一类模块是设备驱动程序, 它为硬件(如串行端口)提供功能。在Unix上, 每个硬件都通过位于\verb|/dev|目录下的设备文件来表示, 这些文件提供了与硬件通信的手段。设备驱动程序代表用户程序提供通信。因此, es1370.ko声卡设备驱动程序可以将/dev/sound设备文件连接到Ensoniq ES1370声卡。像mp3blaster这样的用户空间程序可以使用/dev/sound, 而无需知道安装了何种声卡。 - - 我们可以看一些设备文件。以下是表示串行端口(tty-teletypewriter)上的前三个端口的设备文件: - -\begin{verbatim} -$ ls -l /dev/tty[1-3] -crw--w---- 1 root tty 4, 1 7月28日 15:44 /dev/tty1 -crw--w---- 1 root tty 4, 2 7月28日 15:44 /dev/tty2 -crw--w---- 1 root tty 4, 3 7月28日 15:44 /dev/tty3 -\end{verbatim} - - 请注意日期前方由逗号分隔的数字列(4, 1 ; 4, 2 ; 4, 3)。第一个数字称为设备的主编号。第二个数字是次要数字。主编号告诉你使用哪个驱动程序访问硬件。每个驱动程序都有唯一的一个主编号码；主编号码相同的设备文件都由同一个驱动程序控制。上述所有主编号码都是 4, 因为它们都由同一个驱动程序控制。 - - 次要编号由驱动程序用于区分其控制的各种硬件。回到上面的例子, 尽管所有三个设备都由相同的驱动程序处理, 但它们具有唯一的次要编号, 因为驱动程序将它们视为不同的硬件。 - - 设备分为两种类型: 字符设备和块设备。区别在于块设备具有请求的缓冲区, 因此它们可以选择响应请求的最佳顺序。这一点对存储设备尤为重要, 因为读写相邻的扇区比读写距离较远的扇区更快。另一个区别是, 块设备只能按块接收输入和返回输出(块的大小可以根据设备而变), 而字符设备则可以按需要使用任意数量的字节。世界上大多数设备都是字符型的, 它们不需要这种缓冲不以固定的块大小运行。你可以通过查看\sh|ls -l|输出中的第一个字符来判断设备文件是用于块设备还是字符设备。如果它是"b", 则它是块设备, 如果它是c, 则它为字符设备。上面看到的设备是字符设备。以下是一些块设备(存储): - -\begin{verbatim} -brw-rw---- 1 root disk 7, 0 7月28日 15:44 loop0 -brw-rw---- 1 root disk 7, 1 7月28日 15:44 loop1 -brw-rw---- 1 root disk 7, 2 7月28日 15:44 loop2 -brw-rw---- 1 root disk 7, 3 7月28日 15:44 loop3 -brw-rw---- 1 root disk 7, 4 7月28日 15:44 loop4 -brw-rw---- 1 root disk 7, 5 7月28日 15:44 loop5 -brw-rw---- 1 root disk 7, 6 7月28日 15:44 loop6 -brw-rw---- 1 root disk 7, 7 7月28日 15:44 loop7 -brw-rw---- 1 root disk 259, 0 7月28日 15:44 nvme0n1 -brw-rw---- 1 root disk 259, 1 7月28日 15:44 nvme0n1p1 -brw-rw---- 1 root disk 8, 0 7月28日 15:44 sda -brw-rw---- 1 root disk 8, 1 7月28日 15:44 sda1 -brw-rw---- 1 root disk 8, 2 7月28日 15:44 sda2 -\end{verbatim} - - 如果要查看已分配的主编号, 可以查看\src{Documentation/admin-guide/devices.txt}。 - - 安装系统时, 所有设备文件都是通过\sh|mknod|命令创建的。要创建一个名为\verb|coffee|的新字符设备, 主为12和次为2, 只需执行\sh|mknod /dev/coffee c 12 2|。你不必将设备文件放入\verb|/dev|中, 但这是按照约定完成的。Linus将他的设备文件放在\verb|/dev|中, 你也应该这样。然而, 当为测试目的创建设备文件时, 将其放置在你编译内核模块的工作目录中通常是可以的。但完成设备驱动程序编写后, 确保将其放在正确的位置。 - - 最后需要明确的是当访问设备文件时, 内核使用该文件的主编号来识别处理访问对应的驱动程序。这意味着内核不必依赖或了解次设备号。处理次设备号的是驱动程序本身, 它用次设备号来区分不同的硬件设备。 - - 需要注意的是, 当提到"\emph{"硬件(hardware)"}"时, 该术语的使用比较抽象, 他指的不仅仅是PCI设备。看看以下两个设备文件: - -\begin{verbatim} -ls -l /dev/nvme0n1* /dev/sda -brw-rw---- 1 root disk 259, 0 7月28日 15:44 /dev/nvme0n1 -brw-rw---- 1 root disk 259, 1 7月28日 15:44 /dev/nvme0n1p1 -\end{verbatim} - - 从这两个设备文件的信息你应该能看出它们是块设备, 并且他们是由相同的驱动程序处理(块, 主259)。但是上述具有相同主编号但不同次号的两个设备文件实际上是表示相同的物理硬件。所以请注意, 我们讨论中的"\emph{"硬件(hardware)"}"一词可能意味着一些抽象的东西。 - -\section{字符设备驱动程序} -\label{sec:chardev} -\subsection{文件操作结构} -\label{sec:file_operations} - \cpp|file_operations|结构在\src{include/linux/fs.h}中定义并保存指向驱动程序定义的函数的指针, 这些函数在设备上执行各种操作。结构的每个字段对应于驱动程序定义的某个函数的地址, 以处理请求的操作。 - - 每个字符驱动程序都需要定义从设备读取的函数。\cpp|file_operations|结构保存执行该操作的模块函数的地址。下面是内核5.4的定义: - -\begin{code} -struct file_operations { - struct module *owner; - loff_t (*llseek) (struct file *, loff_t, int); - ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); - ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); - ssize_t (*read_iter) (struct kiocb *, struct iov_iter *); - ssize_t (*write_iter) (struct kiocb *, struct iov_iter *); - int (*iopoll)(struct kiocb *kiocb, bool spin); - int (*iterate) (struct file *, struct dir_context *); - int (*iterate_shared) (struct file *, struct dir_context *); - __poll_t (*poll) (struct file *, struct poll_table_struct *); - long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); - long (*compat_ioctl) (struct file *, unsigned int, unsigned long); - int (*mmap) (struct file *, struct vm_area_struct *); - unsigned long mmap_supported_flags; - int (*open) (struct inode *, struct file *); - int (*flush) (struct file *, fl_owner_t id); - int (*release) (struct inode *, struct file *); - int (*fsync) (struct file *, loff_t, loff_t, int datasync); - int (*fasync) (int, struct file *, int); - int (*lock) (struct file *, int, struct file_lock *); - ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int); - unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long); - int (*check_flags)(int); - int (*flock) (struct file *, int, struct file_lock *); - ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int); - ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int); - int (*setlease)(struct file *, long, struct file_lock **, void **); - long (*fallocate)(struct file *file, int mode, loff_t offset, - loff_t len); - void (*show_fdinfo)(struct seq_file *m, struct file *f); - ssize_t (*copy_file_range)(struct file *, loff_t, struct file *, - loff_t, size_t, unsigned int); - loff_t (*remap_file_range)(struct file *file_in, loff_t pos_in, - struct file *file_out, loff_t pos_out, - loff_t len, unsigned int remap_flags); - int (*fadvise)(struct file *, loff_t, loff_t, int); -} __randomize_layout; -\end{code} - - 一些操作不是由驱动程序实现的。例如, 显卡的驱动程序不需要从目录结构中读取(\cpp|ssize\_t (*read) (struct file *, char \_\_user *, size\_t, loff\_t *);|)。\cpp|file\_operations|结构中的相应条目应设置为\cpp|NULL|。 - - 有一个GCC扩展使分配到此结构更方便。你会在现代的驱动程序中看到它, 这可能会让你感到意外。下面是这种新方式对结构赋值的样子: - -\begin{code} -struct file_operations fops = { - read: device_read, - write: device_write, - open: device_open, - release: device_release -}; -\end{code} - - 但也有一种更常用基于C99标准的方式来分配结构元素, 即\href{https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html}{指定初始化器(designated initializers)}, 与使用GNU扩展相比这种基于C99的分配方法适用性更加广泛。使用此语法有助于增加驱动的兼容性: - -\begin{code} -struct file_operations fops = { - .read = device_read, - .write = device_write, - .open = device_open, - .release = device_release -}; -\end{code} - - 没有显式分配的结构的任何成员都将由GCC初始化为 \cpp|NULL|。 - - 结构 \cpp|struct file\_operations| 的实例包含指向用于实现 \cpp|读取(read)|, \cpp|写入(write)|, \cpp|打开(open)|, \ldots{}系统调用的函数的指针, 通常称为\cpp|fops|。 - - 从 Linux v3.14 开始, 通过使用特定的 \cpp|f\_pos| 锁, 读、写和寻址操作保证了线程安全, 这使得文件位置的更新变成了互斥操作。因此, 我们可以在不需要额外加锁的情况下安全地实现这些操作。 - - 此外, 从Linux v5.6开始, 引入了 \cpp|proc\_ops| 结构, 以取代在注册proc处理程序时使用的 \cpp|file\_operations|结构。请参阅\ref{sec:proc_ops}节中的更多信息。 - -\subsection{文件结构} -\label{sec:file_struct} - - 每个设备在内核中由一个文件结构表示, 该文件结构在 \src{include/linux/fs.h}中定义。这里的文件是内核级结构, 从不出现在用户空间程序中。他与我们常见的由\cpp|glibc|定义\cpp|FILE|是不同的, 由\cpp|glibc|定义的\cpp|FILE|不会出现在内核空间函数中。内核这里的文件(file)命名会产生一些误导；它表示一个抽象的打开"文件(file)", 而不是磁盘上的文件, 该文件由一个名为\cpp|inode|的结构表示。 - - 内核中的结构体 \cpp|文件(file)| 实例通常被称为 filp。你也会看到它被称为 \cpp|结构体文件对象(struct file object)|。不要随意更改这种叫法。 - - 现在我们来看一下"文件(file)"的定义。你会看到许多条目, 例如"结构目录项(struct dentry)", 这些通常不被设备驱动程序使用, 因此你可以忽略它们。这是因为驱动程序并不直接填充"文件(file)"; 它们仅使用文件中的结构体, 这些结构体是在其他地方创建的。 - -\subsection{注册设备} -\label{sec:register_device} - 如之前所讨论的, 按照约定俗成的做法字符设备通过位于 \verb|/dev| 目录下的设备文件来访问。在编写驱动程序时, 将设备文件放在当前目录是可以的。但请确保在生产环境中将其放置在 \verb|/dev| 目录。主编号用于标识哪个驱动程序处理哪个设备文件。次号仅由驱动程序本身使用, 在一个驱动程序处理多个设备时区分它正在操作的设备。 - - 向系统中添加驱动程序意味着向内核注册它。这等同于在模块初始化期间为其分配主编号。你可以通过使用 \cpp|register_chrdev| 函数来实现这一点, 该函数由 \src{include/linux/fs.h} 定义。 - -\begin{code} -int register_chrdev(unsigned int major, const char *name, struct file_operations *fops); -\end{code} - 其中, \cpp|unsigned int major|是要请求的主编号, \cpp|const char *name|是设备的名称, 它将出现在\verb|/proc/devices|中, \cpp|struct file_operations *fops| 是指向驱动程序的 \cpp|file_operations|表的指针。负返回值表示注册失败。我们没有将次号传递给\cpp|register_chrdev|。因为内核不关心次号, 只有我们的驱动使用它。 - - 现在的问题是, 如何获得一个不占用已经在使用中的主编号？最简单的方法是查看 \src{Documentation/admin-guide/devices.txt} 文件选择一个未被使用的编号。但这种做法并不理想, 因为你无法确保你选择的号码以后不会被分配。正确的做法是请求内核为你分配一个动态的主编号。 - - 如果传递给 \cpp|register_chrdev|的值是0, 返回值将是动态分配的主编号。不过, 这样做的缺点是你无法提前创建设备文件, 因为你不知道将会获得什么主编号。处理这种情况有几种方法: 驱动程序本身可以打印新分配的编号, 我们可以手动制作设备文件; 新注册的设备将在\verb|/proc/devices|中有一个条目, 我们可以手动创建设备文件, 也可以编写一个shell脚本来读取文件并创建设备文件; 还有一种方法是, 我们可以让驱动程序在成功注册后使用 \cpp|device_create|函数生成设备文件, 并在调用 \cpp|cleanup_module|期间使用\cpp|device_destroy|。 - -\cpp|register_chrdev()| 函数会占用与指定主编号相关联的一系列次设备号。为了减少字符设备注册时的资源浪费, 推荐使用 cdev 接口。 - - 新接口通过两个步骤完成字符设备的注册。首先注册一系列设备号, 可以用\cpp|register_chrdev_region| 或 \cpp|alloc_chrdev_region|来完成。 - -\begin{code} -int register_chrdev_region(dev_t from, unsigned count, const char *name); -int alloc_chrdev_region(dev_t *dev, unsigned baseminor, unsigned count, const char *name); -\end{code} - - 两种不同功能之间的选择取决于你是否知道设备的主编号。如果知道设备主编号, 则使用\cpp|register_chrdev_region|；如果要分配动态分配的主编号, 请使用\cpp|alloc_chrdev_region|。 - - 其次, 我们应该初始化字符驱动的数据结构\cpp|struct cdev|并将其与设备号相关联。初始化 \cpp|struct cdev| 的代码序列可以参照以下示例来实现。 - -\begin{code} -struct cdev *my_dev = cdev_alloc(); -my_cdev->ops = &my_fops; -\end{code} - - 通常的做法是将 \cpp|struct cdev| 嵌入到设备特定的结构中。在这种情况下, 我们需要使用 \cpp|cdev_init| 来进行初始化。 - -\begin{code} -void cdev_init(struct cdev *cdev, const struct file_operations *fops); -\end{code} - - 一旦完成初始化, 就可以使用\cpp|cdev_add|将字符驱动添加到系统中。 - -\begin{code} -int cdev_add(struct cdev *p, dev_t dev, unsigned count); -\end{code} - - 要查找使用该接口的示例, 可以参阅第\ref{sec:device_files}节中描述的\verb|ioctl.c|。 - -\subsection{注销设备} -\label{sec:unregister_device} - 我们不能让内核模块在root的情况下随意使用 \sh|rmmod| 删除模块。如果有一个进程打开了设备文件, 然后我们移除了内核模块, 再使用该文件将会导致调用已删除函数(如读/写)的内存位置。如果幸运的话, 那里没有加载其他代码, 我们将收到一条错误消息。如果我们运气不好, 另一个内核模块被加载到相同的位置, 这意味着跳转到内核中另一个函数的中间。这种情况的结果是无法预测的, 但肯定不会有什么好结果。 - - 当你不想允许某些操作时, 应该从尝试执行该操作的函数返回一个错误代码(一个负数)。但 \cpp|cleanup_module| 是一个无返回值的函数。然而, 有一个计数器可以跟踪有多少进程正在使用你的模块。你可以通过执行命令 \sh|cat /proc/modules| 或 \sh|sudo lsmod| 查看该计数器的值, 它显示在第三个字段。该数字不为零的时候\sh|rmmod|将执行失败。需要注意的是你不必检查\cpp|cleanup_module|这个计数器, 因为检查将由在\src{include/linux/syscalls.h}中定义的系统调用\cpp|sys_delete_module|中执行。虽然不建议直接使用这个计数器, 但在 \src{include/linux/module.h} 中定义了一些函数, 允许你增加、减少和显示这个计数器的值： - -\begin{itemize} - \item \cpp|try_module_get(THIS_MODULE)|: 增加当前模块的引用计数。 - \item \cpp|module_put(THIS_MODULE)|: 减少当前模块的引用计数。 - \item \cpp|module_refcount(THIS_MODULE)|: 返回当前模块的引用计数的值。 -\end{itemize} - - 保持计数器的准确性是很重要的时期, 如果你让计数器数值出现了异常可能会导致模块永远无法被卸载了, 朋友如果你碰到这种情况了, 那只能靠重启来解决问题了。不过在模块开发过程中, 这种情况迟早会发生。 - -\subsection{chardev.c} -\label{sec:chardev_c} - 下一个代码示例创建一个名为\verb|chardev|的字符驱动程序。你可以转储其设备文件。 - -\begin{codebash} -cat /proc/devices -\end{codebash} - - 驱动程序会将设备文件被读取(或用程序打开文件)的次数记录到文件中。这里不支持写入文件(如 \sh|echo "hi" > /dev/hello|), 但会捕获这些尝试并告诉用户该操作不被支持。不用担心为什么你没有看到这里对读入缓冲区的数据进行了什么操作，因为并没有什么处理。这里只是简单地读入数据后打印一条消息来确认我们收到了它。 - - 在多线程环境中, 如果没有任何保护, 对同一内存的并发访问可能会导致争用情况, 并且会影响性能。在内核模块中, 这个问题可能由于多个实例访问共享资源而发生。因此, 一种解决方案是强制独占访问。我们使用原子性的 CAS(比较和交换, Compare-And-Swap) 来维护状态\cpp|CDEV\_NOT\_USED| 和 \cpp|CDEV\_EXCLUSIVE\_OPEN| 以确定文件当前是否被打开。CAS将存储器位置的内容与期望值进行比较, 并且仅当它们相同时, 才将该存储器位置的内容修改为期望值。有关并发的更多细节，请参阅 \ref{sec:synchronization} 部分。 - -\samplec{examples/chardev.c} - -\subsection{为多个内核版本编写模块} -\label{sec:modules_for_versions} - 系统调用是进程调用内核的主要接口，在不同版本中通常保持不变。在添加新的系统调用时往往会保证旧的系统调用不会发生变化，这对于系统的向后兼容性是非常重要的。内核新版本不会破坏旧进程的正常运行。在大多数情况下，设备文件也应当保持不变。另一方面，内核内部的接口在不同版本之间会存在一些变化。 - - 不同的内核版本之间存在差异, 如果想支持多个内核版本, 则需要编写条件编译指令。实现这一点的方法是比较 \cpp|LINUX_VERSION_CODE| 与 \cpp|KERNEL_VERSION| 这两个宏。在内核的a.b.c版本中, 该宏的值为\(2^{16}a+2^{8}b+c\) - -\section{The /proc File System} -\label{sec:procfs} -In Linux, there is an additional mechanism for the kernel and kernel modules to send information to processes --- the \verb|/proc| file system. -Originally designed to allow easy access to information about processes (hence the name), it is now used by every bit of the kernel which has something interesting to report, such as \verb|/proc/modules| which provides the list of modules and \verb|/proc/meminfo| which gathers memory usage statistics. - -The method to use the proc file system is very similar to the one used with device drivers --- a structure is created with all the information needed for the \verb|/proc| file, including pointers to any handler functions (in our case there is only one, the one called when somebody attempts to read from the \verb|/proc| file). -Then, \cpp|init_module| registers the structure with the kernel and \cpp|cleanup_module| unregisters it. - -Normal file systems are located on a disk, rather than just in memory (which is where \verb|/proc| is), and in that case the index-node (inode for short) number is a pointer to a disk location where the file's inode is located. -The inode contains information about the file, for example the file's permissions, together with a pointer to the disk location or locations where the file's data can be found. - -Because we don't get called when the file is opened or closed, there's nowhere for us to put \cpp|try_module_get| and \cpp|module_put| in this module, and if the file is opened and then the module is removed, there's no way to avoid the consequences. - -Here a simple example showing how to use a \verb|/proc| file. -This is the HelloWorld for the \verb|/proc| filesystem. -There are three parts: create the file \verb|/proc/helloworld| in the function \cpp|init_module|, return a value (and a buffer) when the file \verb|/proc/helloworld| is read in the callback function \cpp|procfile_read|, and delete the file \verb|/proc/helloworld| in the function \cpp|cleanup_module|. - -The \verb|/proc/helloworld| is created when the module is loaded with the function \cpp|proc_create|. -The return value is a pointer to \cpp|struct proc_dir_entry|, and it will be used to configure the file \verb|/proc/helloworld| (for example, the owner of this file). -A null return value means that the creation has failed. - -Every time the file \verb|/proc/helloworld| is read, the function \cpp|procfile_read| is called. -Two parameters of this function are very important: the buffer (the second parameter) and the offset (the fourth one). -The content of the buffer will be returned to the application which read it (for example the \sh|cat| command). -The offset is the current position in the file. -If the return value of the function is not null, then this function is called again. -So be careful with this function, if it never returns zero, the read function is called endlessly. - -\begin{verbatim} -$ cat /proc/helloworld -HelloWorld! -\end{verbatim} - -\samplec{examples/procfs1.c} - -\subsection{The proc\_ops Structure} -\label{sec:proc_ops} -The \cpp|proc_ops| structure is defined in \src{include/linux/proc\_fs.h} in Linux v5.6+. -In older kernels, it used \cpp|file_operations| for custom hooks in \verb|/proc| file system, but it contains some members that are unnecessary in VFS, and every time VFS expands \cpp|file_operations| set, \verb|/proc| code comes bloated. -On the other hand, not only the space, but also some operations were saved by this structure to improve its performance. -For example, the file which never disappears in \verb|/proc| can set the \cpp|proc_flag| as \cpp|PROC_ENTRY_PERMANENT| to save 2 atomic ops, 1 allocation, 1 free in per open/read/close sequence. - -\subsection{Read and Write a /proc File} -\label{sec:read_write_procfs} -We have seen a very simple example for a \verb|/proc| file where we only read the file \verb|/proc/helloworld|. -It is also possible to write in a \verb|/proc| file. -It works the same way as read, a function is called when the \verb|/proc| file is written. -But there is a little difference with read, data comes from user, so you have to import data from user space to kernel space (with \cpp|copy_from_user| or \cpp|get_user|) - -The reason for \cpp|copy_from_user| or \cpp|get_user| is that Linux memory (on Intel architecture, it may be different under some other processors) is segmented. -This means that a pointer, by itself, does not reference a unique location in memory, only a location in a memory segment, and you need to know which memory segment it is to be able to use it. -There is one memory segment for the kernel, and one for each of the processes. - -The only memory segment accessible to a process is its own, so when writing regular programs to run as processes, there is no need to worry about segments. -When you write a kernel module, normally you want to access the kernel memory segment, which is handled automatically by the system. -However, when the content of a memory buffer needs to be passed between the currently running process and the kernel, the kernel function receives a pointer to the memory buffer which is in the process segment. -The \cpp|put_user| and \cpp|get_user| macros allow you to access that memory. -These functions handle only one character, you can handle several characters with \cpp|copy_to_user| and \cpp|copy_from_user|. -As the buffer (in read or write function) is in kernel space, for write function you need to import data because it comes from user space, but not for the read function because data is already in kernel space. - -\samplec{examples/procfs2.c} - -\subsection{Manage /proc file with standard filesystem} -\label{sec:manage_procfs} -We have seen how to read and write a \verb|/proc| file with the \verb|/proc| interface. -But it is also possible to manage \verb|/proc| file with inodes. -The main concern is to use advanced functions, like permissions. - -In Linux, there is a standard mechanism for file system registration. -Since every file system has to have its own functions to handle inode and file operations, there is a special structure to hold pointers to all those functions, \cpp|struct inode_operations|, which includes a pointer to \cpp|struct proc_ops|. - -The difference between file and inode operations is that file operations deal with the file itself whereas inode operations deal with ways of referencing the file, such as creating links to it. - -In \verb|/proc|, whenever we register a new file, we're allowed to specify which \cpp|struct inode_operations| will be used to access to it. -This is the mechanism we use, a \cpp|struct inode_operations| which includes a pointer to a \cpp|struct proc_ops| which includes pointers to our \cpp|procfs_read| and \cpp|procfs_write| functions. - -Another interesting point here is the \cpp|module_permission| function. -This function is called whenever a process tries to do something with the \verb|/proc| file, and it can decide whether to allow access or not. -Right now it is only based on the operation and the uid of the current user (as available in current, a pointer to a structure which includes information on the currently running process), but it could be based on anything we like, such as what other processes are doing with the same file, the time of day, or the last input we received. - -It is important to note that the standard roles of read and write are reversed in the kernel. -Read functions are used for output, whereas write functions are used for input. -The reason for that is that read and write refer to the user's point of view --- if a process reads something from the kernel, then the kernel needs to output it, and if a process writes something to the kernel, then the kernel receives it as input. - -\samplec{examples/procfs3.c} - -Still hungry for procfs examples? -Well, first of all keep in mind, there are rumors around, claiming that procfs is on its way out, consider using \verb|sysfs| instead. -Consider using this mechanism, in case you want to document something kernel related yourself. - -\subsection{Manage /proc file with seq\_file} -\label{sec:manage_procfs_with_seq_file} -As we have seen, writing a \verb|/proc| file may be quite ``complex''. -So to help people writing \verb|/proc| file, there is an API named \cpp|seq_file| that helps formatting a \verb|/proc| file for output. -It is based on sequence, which is composed of 3 functions: \cpp|start()|, \cpp|next()|, and \cpp|stop()|. -The \cpp|seq_file| API starts a sequence when a user read the \verb|/proc| file. - -A sequence begins with the call of the function \cpp|start()|. -If the return is a non \cpp|NULL| value, the function \cpp|next()| is called; otherwise, the \cpp|stop()| function is called directly. -This function is an iterator, the goal is to go through all the data. -Each time \cpp|next()| is called, the function \cpp|show()| is also called. -It writes data values in the buffer read by the user. -The function \cpp|next()| is called until it returns \cpp|NULL|. -The sequence ends when \cpp|next()| returns \cpp|NULL|, then the function \cpp|stop()| is called. - -BE CAREFUL: when a sequence is finished, another one starts. -That means that at the end of function \cpp|stop()|, the function \cpp|start()| is called again. -This loop finishes when the function \cpp|start()| returns \cpp|NULL|. -You can see a scheme of this in the Figure~\ref{img:seqfile}. - -\begin{figure}[h] - \center - \begin{tikzpicture}[node distance=2cm, thick] - \node (start) [startstop] {start() treatment}; - \node (branch1) [decision, below of=start, yshift=-1cm] {return is NULL?}; - \node (next) [process, below of=branch1, yshift=-1cm] {next() treatment}; - \node (branch2) [decision, below of=next, yshift=-1cm] {return is NULL?}; - \node (stop) [startstop, below of=branch2, yshift=-1cm] {stop() treatment}; - - \draw [->] (start) -- (branch1); - \draw [->] (branch1.east) to [out=135, in=-135, bend left=45] node [right] {Yes} (stop.east); - \draw [->] (branch1) -- node[left=2em, anchor=south] {No} (next); - \draw [->] (next) -- (branch2); - \draw [->] (branch2.west) to [out=135, in=-135, bend left=45] node [left] {No} (next.west); - \draw [->] (branch2) -- node[left=2em, anchor=south] {Yes} (stop); - \draw [->] (stop.west) to [out=135, in=-135] node [left] {} (start.west); - \end{tikzpicture} - \caption{How seq\_file works} - \label{img:seqfile} -\end{figure} - -The \cpp|seq_file| provides basic functions for \cpp|proc_ops|, such as \cpp|seq_read|, \cpp|seq_lseek|, and some others. -But nothing to write in the \verb|/proc| file. -Of course, you can still use the same way as in the previous example. - -\samplec{examples/procfs4.c} - -If you want more information, you can read this web page: - -\begin{itemize} - \item \url{https://lwn.net/Articles/22355/} - \item \url{https://kernelnewbies.org/Documents/SeqFileHowTo} -\end{itemize} - -You can also read the code of \src{fs/seq\_file.c} in the linux kernel. - -\section{sysfs: Interacting with your module} -\label{sec:sysfs} -\emph{sysfs} allows you to interact with the running kernel from userspace by reading or setting variables inside of modules. -This can be useful for debugging purposes, or just as an interface for applications or scripts. -You can find sysfs directories and files under the \verb|/sys| directory on your system. - -\begin{codebash} -ls -l /sys -\end{codebash} - -Attributes can be exported for kobjects in the form of regular files in the filesystem. -Sysfs forwards file I/O operations to methods defined for the attributes, providing a means to read and write kernel attributes. - -An attribute definition in simply: - -\begin{code} -struct attribute { - char *name; - struct module *owner; - umode_t mode; -}; - -int sysfs_create_file(struct kobject * kobj, const struct attribute * attr); -void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr); -\end{code} - -For example, the driver model defines \cpp|struct device_attribute| like: - -\begin{code} -struct device_attribute { - struct attribute attr; - ssize_t (*show)(struct device *dev, struct device_attribute *attr, - char *buf); - ssize_t (*store)(struct device *dev, struct device_attribute *attr, - const char *buf, size_t count); -}; - -int device_create_file(struct device *, const struct device_attribute *); -void device_remove_file(struct device *, const struct device_attribute *); -\end{code} - -To read or write attributes, \cpp|show()| or \cpp|store()| method must be specified when declaring the attribute. -For the common cases \src{include/linux/sysfs.h} provides convenience macros (\cpp|__ATTR|, \cpp|__ATTR_RO|, \cpp|__ATTR_WO|, etc.) to make defining attributes easier as well as making code more concise and readable. - -An example of a hello world module which includes the creation of a variable accessible via sysfs is given below. - -\samplec{examples/hello-sysfs.c} - -Make and install the module: - -\begin{codebash} -make -sudo insmod hello-sysfs.ko -\end{codebash} - -Check that it exists: - -\begin{codebash} -sudo lsmod | grep hello_sysfs -\end{codebash} - -What is the current value of \cpp|myvariable| ? - -\begin{codebash} -sudo cat /sys/kernel/mymodule/myvariable -\end{codebash} - -Set the value of \cpp|myvariable| and check that it changed. - -\begin{codebash} -echo "32" | sudo tee /sys/kernel/mymodule/myvariable -sudo cat /sys/kernel/mymodule/myvariable -\end{codebash} - -Finally, remove the test module: - -\begin{codebash} -sudo rmmod hello_sysfs -\end{codebash} - -In the above case, we use a simple kobject to create a directory under sysfs, and communicate with its attributes. -Since Linux v2.6.0, the \cpp|kobject| structure made its appearance. -It was initially meant as a simple way of unifying kernel code which manages reference counted objects. -After a bit of mission creep, it is now the glue that holds much of the device model and its sysfs interface together. -For more information about kobject and sysfs, see \src{Documentation/driver-api/driver-model/driver.rst} and \url{https://lwn.net/Articles/51437/}. - -\section{Talking To Device Files} -\label{sec:device_files} -Device files are supposed to represent physical devices. -Most physical devices are used for output as well as input, so there has to be some mechanism for device drivers in the kernel to get the output to send to the device from processes. -This is done by opening the device file for output and writing to it, just like writing to a file. -In the following example, this is implemented by \cpp|device_write|. - -This is not always enough. -Imagine you had a serial port connected to a modem (even if you have an internal modem, it is still implemented from the CPU's perspective as a serial port connected to a modem, so you don't have to tax your imagination too hard). -The natural thing to do would be to use the device file to write things to the modem (either modem commands or data to be sent through the phone line) and read things from the modem (either responses for commands or the data received through the phone line). -However, this leaves open the question of what to do when you need to talk to the serial port itself, for example to configure the rate at which data is sent and received. - -The answer in Unix is to use a special function called \cpp|ioctl| (short for Input Output ConTroL). -Every device can have its own \cpp|ioctl| commands, which can be read ioctl's (to send information from a process to the kernel), write ioctl's (to return information to a process), both or neither. -Notice here the roles of read and write are reversed again, so in ioctl's read is to send information to the kernel and write is to receive information from the kernel. - -The ioctl function is called with three parameters: the file descriptor of the appropriate device file, the ioctl number, and a parameter, which is of type long so you can use a cast to use it to pass anything. -You will not be able to pass a structure this way, but you will be able to pass a pointer to the structure. -Here is an example: - -\samplec{examples/ioctl.c} - -You can see there is an argument called \cpp|cmd| in \cpp|test_ioctl_ioctl()| function. -It is the ioctl number. -The ioctl number encodes the major device number, the type of the ioctl, the command, and the type of the parameter. -This ioctl number is usually created by a macro call (\cpp|_IO|, \cpp|_IOR|, \cpp|_IOW| or \cpp|_IOWR| --- depending on the type) in a header file. -This header file should then be included both by the programs which will use ioctl (so they can generate the appropriate ioctl's) and by the kernel module (so it can understand it). -In the example below, the header file is \verb|chardev.h| and the program which uses it is \verb|userspace_ioctl.c|. - -If you want to use ioctls in your own kernel modules, it is best to receive an official ioctl assignment, so if you accidentally get somebody else's ioctls, or if they get yours, you'll know something is wrong. -For more information, consult the kernel source tree at \src{Documentation/userspace-api/ioctl/ioctl-number.rst}. - -Also, we need to be careful that concurrent access to the shared resources will lead to the race condition. -The solution is using atomic Compare-And-Swap (CAS), which we mentioned at \ref{sec:chardev_c} section, to enforce the exclusive access. - -\samplec{examples/chardev2.c} - -\samplec{examples/chardev.h} - -\samplec{examples/other/userspace_ioctl.c} - -\section{System Calls} -\label{sec:syscall} -So far, the only thing we've done was to use well defined kernel mechanisms to register \verb|/proc| files and device handlers. -This is fine if you want to do something the kernel programmers thought you'd want, such as write a device driver. -But what if you want to do something unusual, to change the behavior of the system in some way? -Then, you are mostly on your own. - -Should one choose not to use a virtual machine, kernel programming can become risky. -For example, while writing the code below, the \cpp|open()| system call was inadvertently disrupted. -This resulted in an inability to open any files, run programs, or shut down the system, necessitating a restart of the virtual machine. -Fortunately, no critical files were lost in this instance. -However, if such modifications were made on a live, mission-critical system, the consequences could be severe. -To mitigate the risk of file loss, even in a test environment, it is advised to execute \sh|sync| right before using \sh|insmod| and \sh|rmmod|. - -Forget about \verb|/proc| files, forget about device files. -They are just minor details. -Minutiae in the vast expanse of the universe. -The real process to kernel communication mechanism, the one used by all processes, is \emph{system calls}. -When a process requests a service from the kernel (such as opening a file, forking to a new process, or requesting more memory), this is the mechanism used. -If you want to change the behaviour of the kernel in interesting ways, this is the place to do it. -By the way, if you want to see which system calls a program uses, run \sh|strace |. - -In general, a process is not supposed to be able to access the kernel. -It can not access kernel memory and it can't call kernel functions. -The hardware of the CPU enforces this (that is the reason why it is called ``protected mode'' or ``page protection''). - -System calls are an exception to this general rule. -What happens is that the process fills the registers with the appropriate values and then calls a special instruction which jumps to a previously defined location in the kernel (of course, that location is readable by user processes, it is not writable by them). -Under Intel CPUs, this is done by means of interrupt 0x80. The hardware knows that once you jump to this location, you are no longer running in restricted user mode, but as the operating system kernel --- and therefore you're allowed to do whatever you want. - -% FIXME: recent kernel changes the system call entries -The location in the kernel a process can jump to is called \verb|system_call|. -The procedure at that location checks the system call number, which tells the kernel what service the process requested. -Then, it looks at the table of system calls (\cpp|sys_call_table|) to see the address of the kernel function to call. -Then it calls the function, and after it returns, does a few system checks and then return back to the process (or to a different process, if the process time ran out). -If you want to read this code, it is at the source file \verb|arch/$(architecture)/kernel/entry.S|, after the line \cpp|ENTRY(system_call)|. - -So, if we want to change the way a certain system call works, what we need to do is to write our own function to implement it (usually by adding a bit of our own code, and then calling the original function) and then change the pointer at \cpp|sys_call_table| to point to our function. -Because we might be removed later and we don't want to leave the system in an unstable state, it's important for \cpp|cleanup_module| to restore the table to its original state. - -To modify the content of \cpp|sys_call_table|, we need to consider the control register. -A control register is a processor register that changes or controls the general behavior of the CPU. -For x86 architecture, the \verb|cr0| register has various control flags that modify the basic operation of the processor. -The \verb|WP| flag in \verb|cr0| stands for write protection. -Once the \verb|WP| flag is set, the processor disallows further write attempts to the read-only sections -Therefore, we must disable the \verb|WP| flag before modifying \cpp|sys_call_table|. -Since Linux v5.3, the \cpp|write_cr0| function cannot be used because of the sensitive \verb|cr0| bits pinned by the security issue, the attacker may write into CPU control registers to disable CPU protections like write protection. -As a result, we have to provide the custom assembly routine to bypass it. - -However, \cpp|sys_call_table| symbol is unexported to prevent misuse. -But there have few ways to get the symbol, manual symbol lookup and \cpp|kallsyms_lookup_name|. -Here we use both depend on the kernel version. - -Because of the \textit{control-flow integrity}, which is a technique to prevent the redirect execution code from the attacker, for making sure that the indirect calls go to the expected addresses and the return addresses are not changed. -Since Linux v5.7, the kernel patched the series of \textit{control-flow enforcement} (CET) for x86, -and some configurations of GCC, like GCC versions 9 and 10 in Ubuntu Linux, -will add with CET (the \verb|-fcf-protection| option) in the kernel by default. -Using that GCC to compile the kernel with retpoline off may result in CET being enabled in the kernel. -You can use the following command to check out the \verb|-fcf-protection| option is enabled or not: -\begin{verbatim} -$ gcc -v -Q -O2 --help=target | grep protection -Using built-in specs. -COLLECT_GCC=gcc -COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper -... -gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) -COLLECT_GCC_OPTIONS='-v' '-Q' '-O2' '--help=target' '-mtune=generic' '-march=x86-64' - /usr/lib/gcc/x86_64-linux-gnu/9/cc1 -v ... -fcf-protection ... - GNU C17 (Ubuntu 9.3.0-17ubuntu1~20.04) version 9.3.0 (x86_64-linux-gnu) -... -\end{verbatim} -But CET should not be enabled in the kernel, it may break the Kprobes and bpf. -Consequently, CET is disabled since v5.11. -To guarantee the manual symbol lookup worked, we only use up to v5.4. - -Unfortunately, since Linux v5.7 \cpp|kallsyms_lookup_name| is also unexported, it needs certain trick to get the address of \cpp|kallsyms_lookup_name|. -If \cpp|CONFIG_KPROBES| is enabled, we can facilitate the retrieval of function addresses by means of Kprobes to dynamically break into the specific kernel routine. -Kprobes inserts a breakpoint at the entry of function by replacing the first bytes of the probed instruction. -When a CPU hits the breakpoint, registers are stored, and the control will pass to Kprobes. -It passes the addresses of the saved registers and the Kprobe struct to the handler you defined, then executes it. -Kprobes can be registered by symbol name or address. -Within the symbol name, the address will be handled by the kernel. - -Otherwise, specify the address of \cpp|sys_call_table| from \verb|/proc/kallsyms| and \verb|/boot/System.map| into \cpp|sym| parameter. -Following is the sample usage for \verb|/proc/kallsyms|: -\begin{verbatim} -$ sudo grep sys_call_table /proc/kallsyms -ffffffff82000280 R x32_sys_call_table -ffffffff820013a0 R sys_call_table -ffffffff820023e0 R ia32_sys_call_table -$ sudo insmod syscall-steal.ko sym=0xffffffff820013a0 -\end{verbatim} - -Using the address from \verb|/boot/System.map|, be careful about \verb|KASLR| (Kernel Address Space Layout Randomization). -\verb|KASLR| may randomize the address of kernel code and data at every boot time, such as the static address listed in \verb|/boot/System.map| will offset by some entropy. -The purpose of \verb|KASLR| is to protect the kernel space from the attacker. -Without \verb|KASLR|, the attacker may find the target address in the fixed address easily. -Then the attacker can use return-oriented programming to insert some malicious codes to execute or receive the target data by a tampered pointer. -\verb|KASLR| mitigates these kinds of attacks because the attacker cannot immediately know the target address, but a brute-force attack can still work. -If the address of a symbol in \verb|/proc/kallsyms| is different from the address in \verb|/boot/System.map|, \verb|KASLR| is enabled with the kernel, which your system running on. -\begin{verbatim} -$ grep GRUB_CMDLINE_LINUX_DEFAULT /etc/default/grub -GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" -$ sudo grep sys_call_table /boot/System.map-$(uname -r) -ffffffff82000300 R sys_call_table -$ sudo grep sys_call_table /proc/kallsyms -ffffffff820013a0 R sys_call_table -# Reboot -$ sudo grep sys_call_table /boot/System.map-$(uname -r) -ffffffff82000300 R sys_call_table -$ sudo grep sys_call_table /proc/kallsyms -ffffffff86400300 R sys_call_table -\end{verbatim} -If \verb|KASLR| is enabled, we have to take care of the address from \verb|/proc/kallsyms| each time we reboot the machine. -In order to use the address from \verb|/boot/System.map|, make sure that \verb|KASLR| is disabled. -You can add the \verb|nokaslr| for disabling \verb|KASLR| in next booting time: -\begin{verbatim} -$ grep GRUB_CMDLINE_LINUX_DEFAULT /etc/default/grub -GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" -$ sudo perl -i -pe 'm/quiet/ and s//quiet nokaslr/' /etc/default/grub -$ grep quiet /etc/default/grub -GRUB_CMDLINE_LINUX_DEFAULT="quiet nokaslr splash" -$ sudo update-grub -\end{verbatim} - -For more information, check out the following: - -\begin{itemize} - \item \href{https://lwn.net/Articles/804849/}{Cook: Security things in Linux v5.3} - \item \href{https://lwn.net/Articles/12211/}{Unexporting the system call table} - \item \href{https://lwn.net/Articles/810077/}{Control-flow integrity for the kernel} - \item \href{https://lwn.net/Articles/813350/}{Unexporting kallsyms\_lookup\_name()} - \item \href{https://www.kernel.org/doc/Documentation/kprobes.txt}{Kernel Probes (Kprobes)} - \item \href{https://lwn.net/Articles/569635/}{Kernel address space layout randomization} -\end{itemize} - -The source code here is an example of such a kernel module. -We want to ``spy'' on a certain user, and to \cpp|pr_info()| a message whenever that user opens a file. -Towards this end, we replace the system call to open a file with our own function, called \cpp|our_sys_openat|. -This function checks the uid (user's id) of the current process, and if it is equal to the uid we spy on, it calls \cpp|pr_info()| to display the name of the file to be opened. -Then, either way, it calls the original \cpp|openat()| function with the same parameters, to actually open the file. - -The \cpp|init_module| function replaces the appropriate location in \cpp|sys_call_table| and keeps the original pointer in a variable. -The \cpp|cleanup_module| function uses that variable to restore everything back to normal. -This approach is dangerous, because of the possibility of two kernel modules changing the same system call. -Imagine we have two kernel modules, A and B. A's openat system call will be \cpp|A_openat| and B's will be \cpp|B_openat|. -Now, when A is inserted into the kernel, the system call is replaced with \cpp|A_openat|, which will call the original \cpp|sys_openat| when it is done. -Next, B is inserted into the kernel, which replaces the system call with \cpp|B_openat|, which will call what it thinks is the original system call, \cpp|A_openat|, when it's done. - -Now, if B is removed first, everything will be well --- it will simply restore the system call to \cpp|A_openat|, which calls the original. -However, if A is removed and then B is removed, the system will crash. -A's removal will restore the system call to the original, \cpp|sys_openat|, cutting B out of the loop. -Then, when B is removed, it will restore the system call to what it thinks is the original, \cpp|A_openat|, which is no longer in memory. -At first glance, it appears we could solve this particular problem by checking if the system call is equal to our open function and if so not changing it at all (so that B won't change the system call when it is removed), but that will cause an even worse problem. -When A is removed, it sees that the system call was changed to \cpp|B_openat| so that it is no longer pointing to \cpp|A_openat|, so it will not restore it to \cpp|sys_openat| before it is removed from memory. -Unfortunately, \cpp|B_openat| will still try to call \cpp|A_openat| which is no longer there, so that even without removing B the system would crash. - -For x86 architecture, the system call table cannot be used to invoke a system call after commit -\href{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e3ad78334a69b36e107232e337f9d693dcc9df2}{1e3ad78} since v6.9. -This commit has been backported to long term stable kernels, like v5.15.154+, v6.1.85+, v6.6.26+ and v6.8.5+, see this \href{https://stackoverflow.com/a/78607015}{answer} for more details. -In this case, thanks to Kprobes, a hook can be used instead on the system call entry to intercept the system call. - -Note that all the related problems make syscall stealing unfeasible for production use. -In order to keep people from doing potential harmful things \cpp|sys_call_table| is no longer exported. -This means, if you want to do something more than a mere dry run of this example, you will have to patch your current kernel in order to have \cpp|sys_call_table| exported. - -\samplec{examples/syscall-steal.c} - -\section{Blocking Processes and threads} -\label{sec:blocking_process_thread} -\subsection{Sleep} -\label{sec:sleep} -What do you do when somebody asks you for something you can not do right away? -If you are a human being and you are bothered by a human being, the only thing you can say is: "\emph{Not right now, I'm busy. Go away!}". -But if you are a kernel module and you are bothered by a process, you have another possibility. -You can put the process to sleep until you can service it. -After all, processes are being put to sleep by the kernel and woken up all the time (that is the way multiple processes appear to run on the same time on a single CPU). - -This kernel module is an example of this. -The file (called \verb|/proc/sleep|) can only be opened by a single process at a time. -If the file is already open, the kernel module calls \cpp|wait_event_interruptible|. -The easiest way to keep a file open is to open it with: - -\begin{codebash} -tail -f -\end{codebash} - -This function changes the status of the task (a task is the kernel data structure which holds information about a process and the system call it is in, -if any) to \cpp|TASK_INTERRUPTIBLE|, which means that the task will not run until it is woken up somehow, and adds it to WaitQ, the queue of tasks waiting to access the file. -Then, the function calls the scheduler to context switch to a different process, one which has some use for the CPU. - -When a process is done with the file, it closes it, and \cpp|module_close| is called. -That function wakes up all the processes in the queue (there's no mechanism to only wake up one of them). -It then returns and the process which just closed the file can continue to run. -In time, the scheduler decides that that process has had enough and gives control of the CPU to another process. -Eventually, one of the processes which was in the queue will be given control of the CPU by the scheduler. -It starts at the point right after the call to \cpp|wait_event_interruptible|. - -This means that the process is still in kernel mode - as far as the process is concerned, it issued the open system call and the system call has not returned yet. -The process does not know somebody else used the CPU for most of the time between the moment it issued the call and the moment it returned. - -It can then proceed to set a global variable to tell all the other processes that the file is still open and go on with its life. -When the other processes get a piece of the CPU, they'll see that global variable and go back to sleep. - -So we will use \sh|tail -f| to keep the file open in the background, while trying to access it with another process (again in the background, so that we need not switch to a different vt). -As soon as the first background process is killed with kill \%1 , the second is woken up, is able to access the file and finally terminates. - -To make our life more interesting, \cpp|module_close| does not have a monopoly on waking up the processes which wait to access the file. -A signal, such as \emph{Ctrl +c} (\textbf{SIGINT}) can also wake up a process. This is because we used \cpp|wait_event_interruptible|. -We could have used \cpp|wait_event| instead, but that would have resulted in extremely angry users whose \emph{Ctrl+c}'s are ignored. - -In that case, we want to return with \cpp|-EINTR| immediately. This is important so users can, for example, kill the process before it receives the file. - -There is one more point to remember. Some times processes don't want to sleep, they want either to get what they want immediately, or to be told it cannot be done. -Such processes use the \cpp|O_NONBLOCK| flag when opening the file. -The kernel is supposed to respond by returning with the error code \cpp|-EAGAIN| from operations which would otherwise block, such as opening the file in this example. The program \sh|cat_nonblock|, available in the \verb|examples/other| directory, can be used to open a file with \cpp|O_NONBLOCK|. - -\begin{verbatim} -$ sudo insmod sleep.ko -$ cat_nonblock /proc/sleep -Last input: -$ tail -f /proc/sleep & -Last input: -Last input: -Last input: -Last input: -Last input: -Last input: -Last input: -tail: /proc/sleep: file truncated -[1] 6540 -$ cat_nonblock /proc/sleep -Open would block -$ kill %1 -[1]+ Terminated tail -f /proc/sleep -$ cat_nonblock /proc/sleep -Last input: -$ -\end{verbatim} - -\samplec{examples/sleep.c} - -\samplec{examples/other/cat_nonblock.c} - -\subsection{Completions} -\label{sec:completion} -Sometimes one thing should happen before another within a module having multiple threads. -Rather than using \sh|/bin/sleep| commands, the kernel has another way to do this which allows timeouts or interrupts to also happen. - -Completions as code synchronization mechanism have three main parts, initialization of struct completion synchronization object, the waiting or barrier part through \cpp|wait_for_completion()|, and the signalling side through a call to \cpp|complete()|. - -In the subsequent example, two threads are initiated: crank and flywheel. -It is imperative that the crank thread starts before the flywheel thread. -A completion state is established for each of these threads, with a distinct completion defined for both the crank and flywheel threads. -At the exit point of each thread the respective completion state is updated, and \cpp|wait_for_completion| is used by the flywheel thread to ensure that it does not begin prematurely. -The crank thread uses the \cpp|complete_all()| function to update the completion, which lets the flywheel thread continue. - -So even though \cpp|flywheel_thread| is started first you should notice when you load this module and run \sh|dmesg|, that turning the crank always happens first because the flywheel thread waits for the crank thread to complete. - -There are other variations of the \cpp|wait_for_completion| function, which include timeouts or being interrupted, but this basic mechanism is enough for many common situations without adding a lot of complexity. - -\samplec{examples/completions.c} - -\section{Avoiding Collisions and Deadlocks} -\label{sec:synchronization} -If processes running on different CPUs or in different threads try to access the same memory, then it is possible that strange things can happen or your system can lock up. -To avoid this, various types of mutual exclusion kernel functions are available. -These indicate if a section of code is "locked" or "unlocked" so that simultaneous attempts to run it can not happen. -\subsection{Mutex} -\label{sec:mutex} -You can use kernel mutexes (mutual exclusions) in much the same manner that you might deploy them in userland. -This may be all that is needed to avoid collisions in most cases. - -\samplec{examples/example_mutex.c} - -\subsection{Spinlocks} -\label{sec:spinlock} -As the name suggests, spinlocks lock up the CPU that the code is running on, taking 100\% of its resources. -Because of this you should only use the spinlock mechanism around code which is likely to take no more than a few milliseconds to run and so will not noticeably slow anything down from the user's point of view. - -The example here is \verb|"irq safe"| in that if interrupts happen during the lock then they will not be forgotten and will activate when the unlock happens, using the \cpp|flags| variable to retain their state. - -\samplec{examples/example_spinlock.c} - -Taking 100\% of a CPU's resources comes with greater responsibility. -Situations where the kernel code monopolizes a CPU are called \textbf{atomic contexts}. -Holding a spinlock is one of those situations. -Sleeping in atomic contexts may leave the system hanging, as the occupied CPU devotes 100\% of its resources doing nothing but sleeping. -In some worse cases the system may crash. -Thus, sleeping in atomic contexts is considered a bug in the kernel. -They are sometimes called ``sleep-in-atomic-context'' in some materials. - -Note that sleeping here is not limited to calling the sleep functions explicitly. -If subsequent function calls eventually invoke a function that sleeps, it is also considered sleeping. -Thus, it is important to pay attention to functions being used in atomic context. -There's no documentation recording all such functions, but code comments may help. -Sometimes you may find comments in kernel source code stating that a function ``may sleep'', ``might sleep'', or more explicitly ``the caller should not hold a spinlock''. -Those comments are hints that a function may implicitly sleep and must not be called in atomic contexts. - -\subsection{Read and write locks} -\label{sec:rwlock} -Read and write locks are specialised kinds of spinlocks so that you can exclusively read from something or write to something. -Like the earlier spinlocks example, the one below shows an "irq safe" situation in which if other functions were triggered from irqs which might also read and write to whatever you are concerned with then they would not disrupt the logic. -As before it is a good idea to keep anything done within the lock as short as possible so that it does not hang up the system and cause users to start revolting against the tyranny of your module. - -\samplec{examples/example_rwlock.c} - -Of course, if you know for sure that there are no functions triggered by irqs which could possibly interfere with your logic then you can use the simpler \cpp|read_lock(&myrwlock)| and \cpp|read_unlock(&myrwlock)| or the corresponding write functions. -\subsection{Atomic operations} -\label{sec:atomics} -If you are doing simple arithmetic: adding, subtracting or bitwise operations, then there is another way in the multi-CPU and multi-hyperthreaded world to stop other parts of the system from messing with your mojo. -By using atomic operations you can be confident that your addition, subtraction or bit flip did actually happen and was not overwritten by some other shenanigans. -An example is shown below. - -\samplec{examples/example_atomic.c} - -Before the C11 standard adopts the built-in atomic types, the kernel already provided a small set of atomic types by using a bunch of tricky architecture-specific codes. -Implementing the atomic types by C11 atomics may allow the kernel to throw away the architecture-specific codes and letting the kernel code be more friendly to the people who understand the standard. -But there are some problems, such as the memory model of the kernel doesn't match the model formed by the C11 atomics. -For further details, see: -\begin{itemize} - \item \href{https://www.kernel.org/doc/Documentation/atomic_t.txt}{kernel documentation of atomic types} - \item \href{https://lwn.net/Articles/691128/}{Time to move to C11 atomics?} - \item \href{https://lwn.net/Articles/698315/}{Atomic usage patterns in the kernel} -\end{itemize} - -% FIXME: we should rewrite this section -\section{Replacing Print Macros} -\label{sec:print_macros} -\subsection{Replacement} -% FIXME: cross-reference -In Section \ref{sec:preparation}, it was noted that the X Window System and kernel module programming are not conducive to integration. -This remains valid during the development of kernel modules. -However, in practical scenarios, the necessity emerges to relay messages to the tty (teletype) originating the module load command. - -The term ``tty'' originates from \emph{teletype}, which initially referred to a combined keyboard-printer for Unix system communication. -Today, it signifies a text stream abstraction employed by Unix programs, encompassing physical terminals, -xterms in X displays, and network connections like SSH. - -To achieve this, the ``current'' pointer is leveraged to access the active task's tty structure. -Within this structure lies a pointer to a string write function, facilitating the string's transmission to the tty. - -\samplec{examples/print_string.c} - -\subsection{Flashing keyboard LEDs} -\label{sec:flash_kb_led} -In certain conditions, you may desire a simpler and more direct way to communicate to the external world. -Flashing keyboard LEDs can be such a solution: It is an immediate way to attract attention or to display a status condition. -Keyboard LEDs are present on every hardware, they are always visible, they do not need any setup, and their use is rather simple and non-intrusive, compared to writing to a tty or a file. - -From v4.14 to v4.15, the timer API made a series of changes to improve memory safety. -A buffer overflow in the area of a \cpp|timer_list| structure may be able to overwrite the \cpp|function| and \cpp|data| fields, providing the attacker with a way to use return-oriented programming (ROP) to call arbitrary functions within the kernel. -Also, the function prototype of the callback, containing a \cpp|unsigned long| argument, will prevent work from any type checking. -Furthermore, the function prototype with \cpp|unsigned long| argument may be an obstacle to the forward-edge protection of \textit{control-flow integrity}. -Thus, it is better to use a unique prototype to separate from the cluster that takes an \cpp|unsigned long| argument. -The timer callback should be passed a pointer to the \cpp|timer_list| structure rather than an \cpp|unsigned long| argument. -Then, it wraps all the information the callback needs, including the \cpp|timer_list| structure, into a larger structure, and it can use the \cpp|container_of| macro instead of the \cpp|unsigned long| value. -For more information see: \href{https://lwn.net/Articles/735887/}{Improving the kernel timers API}. - -Before Linux v4.14, \cpp|setup_timer| was used to initialize the timer and the \cpp|timer_list| structure looked like: -\begin{code} -struct timer_list { - unsigned long expires; - void (*function)(unsigned long); - unsigned long data; - u32 flags; - /* ... */ -}; - -void setup_timer(struct timer_list *timer, void (*callback)(unsigned long), - unsigned long data); -\end{code} - -Since Linux v4.14, \cpp|timer_setup| is adopted and the kernel step by step converting to \cpp|timer_setup| from \cpp|setup_timer|. -One of the reasons why API was changed is it need to coexist with the old version interface. -Moreover, the \cpp|timer_setup| was implemented by \cpp|setup_timer| at first. -\begin{code} -void timer_setup(struct timer_list *timer, - void (*callback)(struct timer_list *), unsigned int flags); -\end{code} - -The \cpp|setup_timer| was then removed since v4.15. -As a result, the \cpp|timer_list| structure had changed to the following. -\begin{code} -struct timer_list { - unsigned long expires; - void (*function)(struct timer_list *); - u32 flags; - /* ... */ -}; -\end{code} - -The following source code illustrates a minimal kernel module which, when loaded, starts blinking the keyboard LEDs until it is unloaded. - -\samplec{examples/kbleds.c} - -If none of the examples in this chapter fit your debugging needs, there might yet be some other tricks to try. -Ever wondered what \cpp|CONFIG_LL_DEBUG| in \sh|make menuconfig| is good for? -If you activate that you get low level access to the serial port. -While this might not sound very powerful by itself, you can patch \src{kernel/printk.c} or any other essential syscall to print ASCII characters, thus making it possible to trace virtually everything what your code does over a serial line. -If you find yourself porting the kernel to some new and former unsupported architecture, this is usually amongst the first things that should be implemented. -Logging over a netconsole might also be worth a try. - -While you have seen lots of stuff that can be used to aid debugging here, there are some things to be aware of. Debugging is almost always intrusive. -Adding debug code can change the situation enough to make the bug seem to disappear. -Thus, you should keep debug code to a minimum and make sure it does not show up in production code. - -\section{Scheduling Tasks} -\label{sec:scheduling_tasks} -There are two main ways of running tasks: tasklets and work queues. -Tasklets are a quick and easy way of scheduling a single function to be run. -For example, when triggered from an interrupt, whereas work queues are more complicated but also better suited to running multiple things in a sequence. - -It is possible that in future tasklets may be replaced by \textit{threaded irqs}. -However, discussion about that has been ongoing since 2007 (\href{https://lwn.net/Articles/239633}{Eliminating tasklets}), so do not hold your breath. -See the section \ref{sec:irq} if you wish to avoid the tasklet debate. - -\subsection{Tasklets} -\label{sec:tasklet} -Here is an example tasklet module. -The \cpp|tasklet_fn| function runs for a few seconds. -In the meantime, execution of the \cpp|example_tasklet_init| function may continue to the exit point, depending on whether it is interrupted by \textbf{softirq}. - -\samplec{examples/example_tasklet.c} - -So with this example loaded \sh|dmesg| should show: - -\begin{verbatim} -tasklet example init -Example tasklet starts -Example tasklet init continues... -Example tasklet ends -\end{verbatim} -Although tasklet is easy to use, it comes with several drawbacks, and developers are discussing about getting rid of tasklet in linux kernel. -The tasklet callback runs in atomic context, inside a software interrupt, meaning that it cannot sleep or access user-space data, so not all work can be done in a tasklet handler. -Also, the kernel only allows one instance of any given tasklet to be running at any given time; multiple different tasklet callbacks can run in parallel. - -In recent kernels, tasklets can be replaced by workqueues, timers, or threaded interrupts.\footnote{The goal of threaded interrupts is to push more of the work to separate threads, so that the minimum needed for acknowledging an interrupt is reduced, and therefore the time spent handling the interrupt (where it can't handle any other interrupts at the same time) is reduced. -See \url{https://lwn.net/Articles/302043/}.} -While the removal of tasklets remains a longer-term goal, the current kernel contains more than a hundred uses of tasklets. -Now developers are proceeding with the API changes and the macro \cpp|DECLARE_TASKLET_OLD| exists for compatibility. -For further information, see \url{https://lwn.net/Articles/830964/}. - -\subsection{Work queues} -\label{sec:workqueue} -To add a task to the scheduler we can use a workqueue. -The kernel then uses the Completely Fair Scheduler (CFS) to execute work within the queue. - -\samplec{examples/sched.c} - -\section{Interrupt Handlers} -\label{sec:interrupt_handler} -\subsection{Interrupt Handlers} -\label{sec:irq} -Except for the last chapter, everything we did in the kernel so far we have done as a response to a process asking for it, either by dealing with a special file, sending an \cpp|ioctl()|, or issuing a system call. -But the job of the kernel is not just to respond to process requests. -Another job, which is every bit as important, is to speak to the hardware connected to the machine. - -There are two types of interaction between the CPU and the rest of the computer's hardware. -The first type is when the CPU gives orders to the hardware, the other is when the hardware needs to tell the CPU something. -The second, called interrupts, is much harder to implement because it has to be dealt with when convenient for the hardware, not the CPU. -Hardware devices typically have a very small amount of RAM, and if you do not read their information when available, it is lost. - -Under Linux, hardware interrupts are called IRQ's (Interrupt ReQuests). -There are two types of IRQ's, short and long. -A short IRQ is one which is expected to take a very short period of time, during which the rest of the machine will be blocked and no other interrupts will be handled. -A long IRQ is one which can take longer, and during which other interrupts may occur (but not interrupts from the same device). -If at all possible, it is better to declare an interrupt handler to be long. - -When the CPU receives an interrupt, it stops whatever it is doing (unless it is processing a more important interrupt, in which case it will deal with this one only when the more important one is done), -saves certain parameters on the stack and calls the interrupt handler. -This means that certain things are not allowed in the interrupt handler itself, because the system is in an unknown state. -% TODO: add some diagrams -Linux kernel solves the problem by splitting interrupt handling into two parts. -The first part executes right away and masks the interrupt line. -Hardware interrupts must be handled quickly, and that is why we need the second part to handle the heavy work deferred from an interrupt handler. -Historically, BH (Linux naming for \textit{Bottom Halves}) statistically book-keeps the deferred functions. -\textbf{Softirq} and its higher level abstraction, \textbf{Tasklet}, replace BH since Linux 2.3. - -The way to implement this is to call \cpp|request_irq()| to get your interrupt handler called when the relevant IRQ is received. - -In practice IRQ handling can be a bit more complex. -Hardware is often designed in a way that chains two interrupt controllers, so that all the IRQs from interrupt controller B are cascaded to a certain IRQ from interrupt controller A. -Of course, that requires that the kernel finds out which IRQ it really was afterwards and that adds overhead. Other architectures offer some special, very low overhead, so called "fast IRQ" or FIQs. -To take advantage of them requires handlers to be written in assembly language, so they do not really fit into the kernel. -They can be made to work similar to the others, but after that procedure, they are no longer any faster than "common" IRQs. -SMP enabled kernels running on systems with more than one processor need to solve another truckload of problems. -It is not enough to know if a certain IRQs has happened, it's also important to know what CPU(s) it was for. -People still interested in more details, might want to refer to "APIC" now. - -This function receives the IRQ number, the name of the function, flags, a name for \verb|/proc/interrupts| and a parameter to be passed to the interrupt handler. -Usually there is a certain number of IRQs available. -How many IRQs there are is hardware-dependent. - -The flags can be used for specify behaviors of the IRQ. -For example, use \cpp|IRQF_SHARED| to indicate you are willing to share the IRQ with other interrupt handlers (usually because a number of hardware devices sit on the same IRQ); use the \cpp|IRQF_ONESHOT| to indicate that the IRQ is not reenabled after the handler finished. -It should be noted that in some materials, you may encouter another set of IRQ flags named with the \cpp|SA| prefix. -For example, the \cpp|SA_SHIRQ| and the \cpp|SA_INTERRUPT|. -Those are the the IRQ flags in the older kernels. -They have been removed completely. -Today only the \cpp|IRQF| flags are in use. -This function will only succeed if there is not already a handler on this IRQ, or if you are both willing to share. - -\subsection{Detecting button presses} -\label{sec:detect_button} -Many popular single board computers, such as Raspberry Pi or Beagleboards, have a bunch of GPIO pins. -Attaching buttons to those and then having a button press do something is a classic case in which you might need to use interrupts, -so that instead of having the CPU waste time and battery power polling for a change in input state, it is better for the input to trigger the CPU to then run a particular handling function. - -Here is an example where buttons are connected to GPIO numbers 17 and 18 and an LED is connected to GPIO 4. -You can change those numbers to whatever is appropriate for your board. - -\samplec{examples/intrpt.c} - -\subsection{Bottom Half} -\label{sec:bottom_half} -Suppose you want to do a bunch of stuff inside of an interrupt routine. -A common way to do that without rendering the interrupt unavailable for a significant duration is to combine it with a tasklet. -This pushes the bulk of the work off into the scheduler. - -The example below modifies the previous example to also run an additional task when an interrupt is triggered. - -\samplec{examples/bottomhalf.c} - -\subsection{Threaded IRQ} - -Threaded IRQ is a mechanism to organize both top-half and bottom-half of an IRQ at once. -A threaded IRQ splits the one handler in \cpp|request_irq()| into two: one for the top-half, the other for the bottom-half. -The \cpp|request_threaded_irq()| is the function for using threaded IRQs. -Two handlers are registered at once in the \cpp|request_threaded_irq()|. - -Those two handlers run in different context. -The top-half handler runs in interrupt context. -It's the equivalence of the handler passed to the \cpp|request_irq()|. -The bottom-half handler on the other hand runs in its own thread. -This thread is created on registration of a threaded IRQ. -Its sole purpose is to run this bottom-half handler. -This is where a threaded IRQ is ``threaded''. -If \cpp|IRQ_WAKE_THREAD| is returned by the top-half handler, that bottom-half serving thread will wake up. -The thread then runs the bottom-half handler. - -Here is an example of how to do the same thing as before, with top and bottom halves, but using threads. - -\samplec{examples/bh_threaded.c} - -A threaded IRQ is registered using \cpp|request_threaded_irq()|. -This function only takes one additional parameter than the \cpp|request_irq()| -- the bottom-half handling function that runs in its own thread. -In this example it is the \cpp|button_bottom_half()|. -Usage of other parameters are the same as \cpp|request_irq()|. - -Presence of both handlers is not mandatory. -If either of them is not needed, pass the \cpp|NULL| instead. -A \cpp|NULL| top-half handler implies that no action is taken except to wake up the bottom-half serving thread, which runs the bottom-half handler. -Similarly, a \cpp|NULL| bottom-half handler effectively acts as if \cpp|request_irq()| were used. -In fact, this is how \cpp|request_irq()| is implemented. - -Note that passing \cpp|NULL| to both handlers is considered an error and will make registration fail. - -\section{Virtual Input Device Driver} -\label{sec:vinput} -The input device driver is a module that provides a way to communicate with the interaction device via the event. -For example, the keyboard can send the press or release event to tell the kernel what we want to do. -The input device driver will allocate a new input structure with \cpp|input_allocate_device()| and sets up input bitfields, device id, version, etc. -After that, registers it by calling \cpp|input_register_device()|. - -Here is an example, vinput, -It is an API to allow easy development of virtual input drivers. -The drivers needs to export a \cpp|vinput_device()| that contains the virtual device name and \cpp|vinput_ops| structure that describes: - -\begin{itemize} - \item the init function: \cpp|init()| - \item the input event injection function: \cpp|send()| - \item the readback function: \cpp|read()| -\end{itemize} - -Then using \cpp|vinput_register_device()| and \cpp|vinput_unregister_device()| will add a new device to the list of support virtual input devices. - -\begin{code} -int init(struct vinput *); -\end{code} - -This function is passed a \cpp|struct vinput| already initialized with an allocated \cpp|struct input_dev|. -The \cpp|init()| function is responsible for initializing the capabilities of the input device and register it. - -\begin{code} -int send(struct vinput *, char *, int); -\end{code} - -This function will receive a user string to interpret and inject the event using the \cpp|input_report_XXXX| or \cpp|input_event| call. -The string is already copied from user. - -\begin{code} -int read(struct vinput *, char *, int); -\end{code} - -This function is used for debugging and should fill the buffer parameter with the last event sent in the virtual input device format. -The buffer will then be copied to user. - -vinput devices are created and destroyed using sysfs. -And, event injection is done through a \verb|/dev| node. -The device name will be used by the userland to export a new virtual input device. - -The \cpp|class_attribute| structure is similar to other attribute types we talked about in section \ref{sec:sysfs}: - -\begin{code} -struct class_attribute { - struct attribute attr; - ssize_t (*show)(struct class *class, struct class_attribute *attr, - char *buf); - ssize_t (*store)(struct class *class, struct class_attribute *attr, - const char *buf, size_t count); -}; -\end{code} - -In \verb|vinput.c|, the macro \cpp|CLASS_ATTR_WO(export/unexport)| defined in \src{include/linux/device.h} (in this case, \verb|device.h| is included in \src{include/linux/input.h}) will generate the \cpp|class_attribute| structures which are named \verb|class_attr_export/unexport|. -Then, put them into \cpp|vinput_class_attrs| array and the macro \cpp|ATTRIBUTE_GROUPS(vinput_class)| will generate the \cpp|struct attribute_group vinput_class_group| that should be assigned in \cpp|vinput_class|. -Finally, call \cpp|class_register(&vinput_class)| to create attributes in sysfs. - -To create a \verb|vinputX| sysfs entry and \verb|/dev| node. - -\begin{codebash} -echo "vkbd" | sudo tee /sys/class/vinput/export -\end{codebash} - -To unexport the device, just echo its id in unexport: - -\begin{codebash} -echo "0" | sudo tee /sys/class/vinput/unexport -\end{codebash} - -\samplec{examples/vinput.h} -\samplec{examples/vinput.c} - -Here the virtual keyboard is one of example to use vinput. -It supports all \cpp|KEY_MAX| keycodes. -The injection format is the \cpp|KEY_CODE| such as defined in \src{include/linux/input.h}. -A positive value means \cpp|KEY_PRESS| while a negative value is a \cpp|KEY_RELEASE|. -The keyboard supports repetition when the key stays pressed for too long. -The following demonstrates how simulation work. - -Simulate a key press on "g" (\cpp|KEY_G| = 34): - -\begin{codebash} -echo "+34" | sudo tee /dev/vinput0 -\end{codebash} - -Simulate a key release on "g" (\cpp|KEY_G| = 34): - -\begin{codebash} -echo "-34" | sudo tee /dev/vinput0 -\end{codebash} - -\samplec{examples/vkbd.c} - -% TODO: Add vts.c and vmouse.c example - -\section{Standardizing the interfaces: The Device Model} -\label{sec:device_model} -Up to this point we have seen all kinds of modules doing all kinds of things, but there was no consistency in their interfaces with the rest of the kernel. -To impose some consistency such that there is at minimum a standardized way to start, suspend and resume a device model was added. -An example is shown below, and you can use this as a template to add your own suspend, resume or other interface functions. - -\samplec{examples/devicemodel.c} - -\section{Optimizations} -\label{sec:optimization} -\subsection{Likely and Unlikely conditions} -\label{sec:likely_unlikely} -Sometimes you might want your code to run as quickly as possible, especially if it is handling an interrupt or doing something which might cause noticeable latency. -If your code contains boolean conditions and if you know that the conditions are almost always likely to evaluate as either \cpp|true| or \cpp|false|, -then you can allow the compiler to optimize for this using the \cpp|likely| and \cpp|unlikely| macros. -For example, when allocating memory you are almost always expecting this to succeed. - -\begin{code} -bvl = bvec_alloc(gfp_mask, nr_iovecs, &idx); -if (unlikely(!bvl)) { - mempool_free(bio, bio_pool); - bio = NULL; - goto out; -} -\end{code} - -When the \cpp|unlikely| macro is used, the compiler alters its machine instruction output, so that it continues along the false branch and only jumps if the condition is true. -That avoids flushing the processor pipeline. -The opposite happens if you use the \cpp|likely| macro. - -\subsection{Static keys} -\label{sec:static_keys} -Static keys allow us to enable or disable kernel code paths based on the runtime state of key. Its APIs have been available since 2010 (most architectures are already supported), use self-modifying code to eliminate the overhead of cache and branch prediction. -The most typical use case of static keys is for performance-sensitive kernel code, such as tracepoints, context switching, networking, etc. These hot paths of the kernel often contain branches and can be optimized easily using this technique. -Before we can use static keys in the kernel, we need to make sure that gcc supports \cpp|asm goto| inline assembly, and the following kernel configurations are set: - -\begin{code} -CONFIG_JUMP_LABEL=y -CONFIG_HAVE_ARCH_JUMP_LABEL=y -CONFIG_HAVE_ARCH_JUMP_LABEL_RELATIVE=y -\end{code} - -To declare a static key, we need to define a global variable using the \cpp|DEFINE_STATIC_KEY_FALSE| or \cpp|DEFINE_STATIC_KEY_TRUE| macro defined in \src{include/linux/jump\_label.h}. -This macro initializes the key with the given initial value, which is either false or true, respectively. For example, to declare a static key with an initial value of false, we can use the following code: - -\begin{code} -DEFINE_STATIC_KEY_FALSE(fkey); -\end{code} - -Once the static key has been declared, we need to add branching code to the module that uses the static key. -For example, the code includes a fastpath, where a no-op instruction will be generated at compile time as the key is initialized to false and the branch is unlikely to be taken. - -\begin{code} -pr_info("fastpath 1\n"); -if (static_branch_unlikely(&fkey)) - pr_alert("do unlikely thing\n"); -pr_info("fastpath 2\n"); -\end{code} - -If the key is enabled at runtime by calling \cpp|static_branch_enable(&fkey)|, the fastpath will be patched with an unconditional jump instruction to the slowpath code \cpp|pr_alert|, so the branch will always be taken until the key is disabled again. - -The following kernel module derived from \verb|chardev.c|, demonstrates how the static key works. - -\samplec{examples/static_key.c} - -To check the state of the static key, we can use the \verb|/dev/key_state| interface. - -\begin{codebash} -cat /dev/key_state -\end{codebash} - -This will display the current state of the key, which is disabled by default. - -To change the state of the static key, we can perform a write operation on the file: - -\begin{codebash} -echo enable > /dev/key_state -\end{codebash} - -This will enable the static key, causing the code path to switch from the fastpath to the slowpath. - -In some cases, the key is enabled or disabled at initialization and never changed, we can declare a static key as read-only, which means that it can only be toggled in the module init function. To declare a read-only static key, we can use the \cpp|DEFINE_STATIC_KEY_FALSE_RO| or \cpp|DEFINE_STATIC_KEY_TRUE_RO| macro instead. Attempts to change the key at runtime will result in a page fault. -For more information, see \href{https://www.kernel.org/doc/Documentation/static-keys.txt}{Static keys} - -\section{Common Pitfalls} -\label{sec:opitfall} - -\subsection{Using standard libraries} -\label{sec:using_stdlib} -You can not do that. -In a kernel module, you can only use kernel functions which are the functions you can see in \verb|/proc/kallsyms|. - -\subsection{Disabling interrupts} -\label{sec:disabling_interrupts} -You might need to do this for a short time and that is OK, but if you do not enable them afterwards, your system will be stuck and you will have to power it off. - -\section{Where To Go From Here?} -\label{sec:where_to_go} -For those deeply interested in kernel programming, -\href{https://kernelnewbies.org}{kernelnewbies.org} and the \src{Documentation} subdirectory within the kernel source code are highly recommended. -Although the latter may not always be straightforward, it serves as a valuable initial step for further exploration. -Echoing Linus Torvalds' perspective, the most effective method to understand the kernel is through personal examination of the source code. - -Contributions to this guide are welcome, especially if there are any significant inaccuracies identified. -To contribute or report an issue, please initiate an issue at \url{https://github.com/sysprog21/lkmpg}. -Pull requests are greatly appreciated. - -Happy hacking! -\end{CJK*} -\end{document} diff --git a/nhmk.md b/nhmk.md deleted file mode 100644 index 95d39f8..0000000 --- a/nhmk.md +++ /dev/null @@ -1,2645 +0,0 @@ -_[image](assets/cover-with-names.png) - -Introduction -============ - -The Linux Kernel Module Programming Guide is a free book; you may -reproduce and/or modify it under the terms of the [Open Software -License](https://opensource.org/licenses/OSL-3.0), version 3.0. - -This book is distributed in the hope that it would be useful, but -without any warranty, without even the implied warranty of -merchantability or fitness for a particular purpose. - -The author encourages wide distribution of this book for personal or -commercial use, provided the above copyright notice remains intact and -the method adheres to the provisions of the [Open Software -License](https://opensource.org/licenses/OSL-3.0). In summary, you may -copy and distribute this book free of charge or for a profit. No -explicit permission is required from the author for reproduction of this -book in any medium, physical or electronic. - -Derivative works and translations of this document must be placed under -the Open Software License, and the original copyright notice must remain -intact. If you have contributed new material to this book, you must make -the material and source code available for your revisions. Please make -revisions and updates available directly to the document maintainer, Jim -Huang <jserv@ccns.ncku.edu.tw>. This will allow for the merging of -updates and provide consistent revisions to the Linux community. - -If you publish or distribute this book commercially, donations, -royalties, and/or printed copies are greatly appreciated by the author -and the [Linux Documentation Project](https://tldp.org/) (LDP). -Contributing in this way shows your support for free software and the -LDP. If you have questions or comments, please contact the address -above. - -Authorship ----------- - -The Linux Kernel Module Programming Guide was initially authored by Ori -Pomerantz for Linux v2.2. As the Linux kernel evolved, Ori’s -availability to maintain the document diminished. Consequently, Peter -Jay Salzman assumed the role of maintainer and updated the guide for -Linux v2.4. Similar constraints arose for Peter when tracking -developments in Linux v2.6, leading to Michael Burian joining as a -co-maintainer to bring the guide up to speed with Linux v2.6. Bob -Mottram contributed to the guide by updating examples for Linux v3.8 and -later. Jim Huang then undertook the task of updating the guide for -recent Linux versions (v5.0 and beyond), along with revising the LaTeX -document. - -Acknowledgements ----------------- - -The following people have contributed corrections or good suggestions: - -Amit Dhingra, Andy Shevchenko, Arush Sharma, Benno Bielmeier, Bob Lee, -Brad Baker, Che-Chia Chang, Cheng-Shian Yeh, Chih-En Lin, Chih-Hsuan -Yang, Chih-Yu Chen, Ching-Hua (Vivian) Lin, Chin Yik Ming, cvvletter, -Cyril Brulebois, Daniele Paolo Scarpazza, David Porter, demonsome, Dimo -Velev, Ekang Monyet, Ethan Chan, Francois Audeon, Gilad Reti, -heartofrain, Horst Schirmeier, Hsin-Hsiang Peng, Ignacio Martin, I-Hsin -Cheng, Iûnn Kiàn-îng, Jian-Xing Wu, Johan Calle, keytouch, Kohei Otsuka, -Kuan-Wei Chiu, manbing, Marconi Jiang, mengxinayan, Meng-Zong Tsai, -Peter Lin, Roman Lakeev, Sam Erickson, Shao-Tse Hung, Shih-Sheng Yang, -Stacy Prowell, Steven Lung, Tristan Lelong, Tse-Wei Lin, Tucker Polomik, -Tyler Fanelli, VxTeemo, Wei-Hsin Yeh, Wei-Lun Tsai, Xatierlike Lee, -Yen-Yu Chen, Yin-Chiuan Chen, Yi-Wei Lin, Yo-Jung Lin, Yu-Hsiang Tseng, -YYGO. - -What Is A Kernel Module? ------------------------- - -Involvement in the development of Linux kernel modules requires a -foundation in the C programming language and a track record of creating -conventional programs intended for process execution. This pursuit -delves into a domain where an unregulated pointer, if disregarded, may -potentially trigger the total elimination of an entire file system, -resulting in a scenario that necessitates a complete system reboot. - -A Linux kernel module is precisely defined as a code segment capable of -dynamic loading and unloading within the kernel as needed. These modules -enhance kernel capabilities without necessitating a system reboot. A -notable example is seen in the device driver module, which facilitates -kernel interaction with hardware components linked to the system. In the -absence of modules, the prevailing approach leans toward monolithic -kernels, requiring direct integration of new functionalities into the -kernel image. This approach leads to larger kernels and necessitates -kernel rebuilding and subsequent system rebooting when new -functionalities are desired. - -Kernel module package ---------------------- - -Linux distributions provide the commands |modprobe|, |insmod| and -|depmod| within a package. - -On Ubuntu/Debian GNU/Linux: - -sudo apt-get install build-essential kmod - -On Arch Linux: - -sudo pacman -S gcc kmod - -What Modules are in my Kernel? ------------------------------- - -To discover what modules are already loaded within your current kernel -use the command |lsmod|. - -sudo lsmod - -Modules are stored within the file `/proc/modules`, so you can also see -them with: - -sudo cat /proc/modules - -This can be a long list, and you might prefer to search for something -particular. To search for the `fat` module: - -sudo lsmod | grep fat - -Is there a need to download and compile the kernel? ---------------------------------------------------- - -To effectively follow this guide, there is no obligatory requirement for -performing such actions. Nonetheless, a prudent approach involves -executing the examples within a test distribution on a virtual machine, -thus mitigating any potential risk of disrupting the system. - -Before We Begin ---------------- - -Before delving into code, certain matters require attention. Variances -exist among individuals’ systems, and distinct personal approaches are -evident. The achievement of successful compilation and loading of the -inaugural “hello world” program may, at times, present challenges. It is -reassuring to note that overcoming the initial obstacle in the first -attempt paves the way for subsequent endeavors to proceed seamlessly. - -1. Modversioning. A module compiled for one kernel will not load if a - different kernel is booted, unless |CONFIG_\*-\*-\*_MODVERSIONS| is - enabled in the kernel. Module versioning will be discussed later in - this guide. Until module versioning is covered, the examples in this - guide may not work correctly if running a kernel with modversioning - turned on. However, most stock Linux distribution kernels come with - modversioning enabled. If difficulties arise when loading the - modules due to versioning errors, consider compiling a kernel with - modversioning turned off. - -2. Using X Window System. It is highly recommended to extract, compile, - and load all the examples discussed in this guide from a console. - Working on these tasks within the X Window System is discouraged. - - Modules cannot directly print to the screen like |printf()| can, but - they can log information and warnings that are eventually displayed - on the screen, specifically within a console. If a module is loaded - from an |xterm|, the information and warnings will be logged, but - solely within the systemd journal. These logs will not be visible - unless consulting the |journalctl|. Refer to - 4 - for more information. For instant access to this information, it is - advisable to perform all tasks from the console. - -3. SecureBoot. Numerous modern computers arrive pre-configured with - UEFI SecureBoot enabled—an essential security standard ensuring - booting exclusively through trusted software endorsed by the - original equipment manufacturer. Certain Linux distributions even - ship with the default Linux kernel configured to support SecureBoot. - In these cases, the kernel module necessitates a signed security - key. - - Failing this, an attempt to insert your first “hello world” module - would result in the message: “*ERROR: could not insert module*”. If - this message *Lockdown: insmod: unsigned module loading is - restricted; see man kernel lockdown.7* appears in the |dmesg| - output, the simplest approach involves disabling UEFI SecureBoot - from the boot menu of your PC or laptop, allowing the successful - insertion of “hello world” module. Naturally, an alternative - involves undergoing intricate procedures such as generating keys, - system key installation, and module signing to achieve - functionality. However, this intricate process is less appropriate - for beginners. If interested, more detailed steps for - [SecureBoot](https://wiki.debian.org/SecureBoot) can be explored and - followed. - -Headers -======= - -Before building anything, it is necessary to install the header files -for the kernel. - -On Ubuntu/Debian GNU/Linux: - -sudo apt-get update apt-cache search linux-headers-‘uname -r‘ - -The following command provides information on the available kernel -header files. Then for example: - -sudo apt-get install kmod linux-headers-5.4.0-80-generic - -On Arch Linux: - -sudo pacman -S linux-headers - -On Fedora: - -sudo dnf install kernel-devel kernel-headers - -Examples -======== - -All the examples from this document are available within the `examples` -subdirectory. - -Should compile errors occur, it may be due to a more recent kernel -version being in use, or there might be a need to install the -corresponding kernel header files. - -Hello World -=========== - -The Simplest Module -------------------- - -Most individuals beginning their programming journey typically start -with some variant of a *hello world* example. It is unclear what the -outcomes are for those who deviate from this tradition, but it seems -prudent to adhere to it. The learning process will begin with a series -of hello world programs that illustrate various fundamental aspects of -writing a kernel module. - -Presented next is the simplest possible module. - -Make a test directory: - -mkdir -p  /develop/kernel/hello-1 cd  /develop/kernel/hello-1 - -Paste this into your favorite editor and save it as `hello-1.c`: - -Now you will need a `Makefile`. If you copy and paste this, change the -indentation to use *tabs*, not spaces. - -In `Makefile`, `$(CURDIR)` can set to the absolute pathname of the -current working directory(after all `-C` options are processed, if any). -See more about `CURDIR` in [GNU make -manual](https://www.gnu.org/software/make/manual/make.html). - -And finally, just run `make` directly. - -make - -If there is no `PWD := $(CURDIR)` statement in Makefile, then it may not -compile correctly with `sudo make`. Because some environment variables -are specified by the security policy, they can’t be inherited. The -default security policy is `sudoers`. In the `sudoers` security policy, -`env_*-*-*_reset` is enabled by default, which restricts environment -variables. Specifically, path variables are not retained from the user -environment, they are set to default values (For more information see: -[sudoers manual](https://www.sudo.ws/docs/man/sudoers.man/)). You can -see the environment variable settings by: - - $ sudo -s - # sudo -V - -Here is a simple Makefile as an example to demonstrate the problem -mentioned above. - -all: echo $(PWD) -\\end{code} - -Then, we can use \\verb|-p| flag to print out the environment variable values from the Makefile. - -\\begin{verbatim}$ make -p | grep PWD PWD = /home/ubuntu/temp OLDPWD = -/home/ubuntu echo $(PWD) -\\end{verbatim} - -The \\verb|PWD| variable won't be inherited with \\verb|sudo|. - -\\begin{verbatim}$ sudo make -p | grep PWD echo $(PWD) -\\end{verbatim} - -However, there are three ways to solve this problem. - -\\begin{enumerate} - \\item { - You can use the \\verb|-E| flag to temporarily preserve them. - - \\begin{codebash} - $ sudo -E make -p | grep PWD - PWD = /home/ubuntu/temp - OLDPWD = /home/ubuntu - echo $(PWD) - \\end{codebash} - } - - \\item { - You can set the \\verb|env_\*-\*-\*_reset| disabled by editing the \\verb|/etc/sudoers| with root and \\verb|visudo|. - - \\begin{code} - \#\# sudoers file. - \#\# - ... - Defaults env_\*-\*-\*_reset - \#\# Change env_\*-\*-\*_reset to _env_\*-\*-\*_reset in previous line to keep all environment variables - \\end{code} - - Then execute \\verb|env| and \\verb|sudo env| individually. - - \\begin{codebash} - \# disable the env_\*-\*-\*_reset - echo "user:" > non-env_\*-\*-\*_reset.log; env >> non-env_\*-\*-\*_reset.log - echo "root:" >> non-env_\*-\*-\*_reset.log; sudo env >> non-env_\*-\*-\*_reset.log - \# enable the env_\*-\*-\*_reset - echo "user:" > env_\*-\*-\*_reset.log; env >> env_\*-\*-\*_reset.log - echo "root:" >> env_\*-\*-\*_reset.log; sudo env >> env_\*-\*-\*_reset.log - \\end{codebash} - - You can view and compare these logs to find differences between \\verb|env_\*-\*-\*_reset| and \\verb|_env_\*-\*-\*_reset|. - } - - \\item {You can preserve environment variables by appending them to \\verb|env_\*-\*-\*_keep| in \\verb|/etc/sudoers|. - - \\begin{code} - Defaults env_\*-\*-\*_keep += "PWD" - \\end{code} - - After applying the above change, you can check the environment variable settings by: - - \\begin{verbatim} - $ sudo -s - \# sudo -V - \\end{verbatim} - } -\\end{enumerate} - -If all goes smoothly you should then find that you have a compiled \\verb|hello-1.ko| module. -You can find info on it with the command: -\\begin{codebash} -modinfo hello-1.ko -\\end{codebash} - -At this point the command: -\\begin{codebash} -sudo lsmod | grep hello -\\end{codebash} - -should return nothing. -You can try loading your shiny new module with: -\\begin{codebash} -sudo insmod hello-1.ko -\\end{codebash} - -The dash character will get converted to an underscore, so when you again try: -\\begin{codebash} -sudo lsmod | grep hello -\\end{codebash} - -You should now see your loaded module. It can be removed again with: -\\begin{codebash} -sudo rmmod hello_\*-\*-\*_1 -\\end{codebash} - -Notice that the dash was replaced by an underscore. -To see what just happened in the logs: -\\begin{codebash} -sudo journalctl --since "1 hour ago" | grep kernel -\\end{codebash} - -You now know the basics of creating, compiling, installing and removing modules. -Now for more of a description of how this module works. - -Kernel modules must have at least two functions: a "start" (initialization) function called \\cpp|init_\*-\*-\*_module()| which is called when the module is \\sh|insmod|ed into the kernel, and an "end" (cleanup) function called \\cpp|cleanup_\*-\*-\*_module()| which is called just before it is removed from the kernel. -Actually, things have changed starting with kernel 2.3.13. -% TODO: adjust the section anchor -You can now use whatever name you like for the start and end functions of a module, and you will learn how to do this in Section \\ref{hello_\*-\*-\*_n_\*-\*-\*_goodbye}. -In fact, the new method is the preferred method. -However, many people still use \\cpp|init_\*-\*-\*_module()| and \\cpp|cleanup_\*-\*-\*_module()| for their start and end functions. - -Typically, \\cpp|init_\*-\*-\*_module()| either registers a handler for something with the kernel, or it replaces one of the kernel functions with its own code (usually code to do something and then call the original function). -The \\cpp|cleanup_\*-\*-\*_module()| function is supposed to undo whatever \\cpp|init_\*-\*-\*_module()| did, so the module can be unloaded safely. - -Lastly, every kernel module needs to include \\verb|<linux/module.h>|. -% TODO: adjust the section anchor -We needed to include \\verb|<linux/printk.h>| only for the macro expansion for the \\cpp|pr_\*-\*-\*_alert()| log level, which you'll learn about in Section \\ref{sec:printk}. - -\\begin{enumerate} - \\item A point about coding style. - Another thing which may not be immediately obvious to anyone getting started with kernel programming is that indentation within your code should be using \\textbf{tabs} and \\textbf{not spaces}. - It is one of the coding conventions of the kernel. - You may not like it, but you'll need to get used to it if you ever submit a patch upstream. - - \\item Introducing print macros. - \\label{sec:printk} - In the beginning there was \\cpp|printk|, usually followed by a priority such as \\cpp|KERN_\*-\*-\*_INFO| or \\cpp|KERN_\*-\*-\*_DEBUG|. - More recently this can also be expressed in abbreviated form using a set of print macros, such as \\cpp|pr_\*-\*-\*_info| and \\cpp|pr_\*-\*-\*_debug|. - This just saves some mindless keyboard bashing and looks a bit neater. - They can be found within \\href{https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/printk.h}% - {\\ifthenelse{\\equal{}{}}{include/linux/printk.h}{}}. - Take time to read through the available priority macros. - - \\item About Compiling. - Kernel modules need to be compiled a bit differently from regular userspace apps. - Former kernel versions required us to care much about these settings, which are usually stored in Makefiles. - Although hierarchically organized, many redundant settings accumulated in sublevel Makefiles and made them large and rather difficult to maintain. - Fortunately, there is a new way of doing these things, called kbuild, and the build process for external loadable modules is now fully integrated into the standard kernel build mechanism. - To learn more on how to compile modules which are not part of the official kernel (such as all the examples you will find in this guide), see file \\href{https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/kbuild/modules.rst}% - {\\ifthenelse{\\equal{}{}}{Documentation/kbuild/modules.rst}{}}. - - Additional details about Makefiles for kernel modules are available in \\href{https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/kbuild/makefiles.rst}% - {\\ifthenelse{\\equal{}{}}{Documentation/kbuild/makefiles.rst}{}}. Be sure to read this and the related files before starting to hack Makefiles. It will probably save you lots of work. - -\\begin{quote} -Here is another exercise for the reader. -See that comment above the return statement in \\cpp|init_\*-\*-\*_module()|? -Change the return value to something negative, recompile and load the module again. -What happens? -\\end{quote} -\\end{enumerate} - -\\subsection{Hello and Goodbye} -\\label{hello_\*-\*-\*_n_\*-\*-\*_goodbye} -In early kernel versions you had to use the \\cpp|init_\*-\*-\*_module| and \\cpp|cleanup_\*-\*-\*_module| functions, as in the first hello world example, but these days you can name those anything you want by using the \\cpp|module_\*-\*-\*_init| and \\cpp|module_\*-\*-\*_exit| macros. -These macros are defined in \\href{https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/module.h}% - {\\ifthenelse{\\equal{}{}}{include/linux/module.h}{}}. -The only requirement is that your init and cleanup functions must be defined before calling the those macros, otherwise you'll get compilation errors. -Here is an example of this technique: - -\\samplec{examples/hello-2.c} - -So now we have two real kernel modules under our belt. Adding another module is as simple as this: - -\\begin{code} -obj-m += hello-1.o -obj-m += hello-2.o - -PWD :=$(CURDIR) - -all: make -C -/lib/modules/(*s**h**e**l**l**u**n**a**m**e* − *r*)/*b**u**i**l**d**M*=(PWD) -modules - -clean: make -C -/lib/modules/(*s**h**e**l**l**u**n**a**m**e* − *r*)/*b**u**i**l**d**M*=(PWD) -clean - -Now have a look at -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/char/Makefile) -for a real world example. As you can see, some things got hardwired into -the kernel (`obj-y`) but where have all those `obj-m` gone? Those -familiar with shell scripts will easily be able to spot them. For those -who are not, the `obj-$(CONFIG_*-*-*_FOO)` entries you see everywhere -expand into `obj-y` or `obj-m`, depending on whether the -`CONFIG_*-*-*_FOO` variable has been set to `y` or `m`. While we are at -it, those were exactly the kind of variables that you have set in the -`.config` file in the top-level directory of Linux kernel source tree, -the last time when you said |make menuconfig| or something like that. - -The -\*-\*_-\*-\*_init and -\*-\*_-\*-\*_exit Macros ----------------------------------------------------- - -The |_\*-\*-\*_\*-\*-\*_init| macro causes the init function to be -discarded and its memory freed once the init function finishes for -built-in drivers, but not loadable modules. If you think about when the -init function is invoked, this makes perfect sense. - -There is also an |_\*-\*-\*_\*-\*-\*_initdata| which works similarly to -|_\*-\*-\*_\*-\*-\*_init| but for init variables rather than functions. - -The |_\*-\*-\*_\*-\*-\*_exit| macro causes the omission of the function -when the module is built into the kernel, and like -|_\*-\*-\*_\*-\*-\*_init|, has no effect for loadable modules. Again, -if you consider when the cleanup function runs, this makes complete -sense; built-in drivers do not need a cleanup function, while loadable -modules do. - -These macros are defined in -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/init.h) -and serve to free up kernel memory. When you boot your kernel and see -something like Freeing unused kernel memory: 236k freed, this is -precisely what the kernel is freeing. - -Licensing and Module Documentation ----------------------------------- - -Honestly, who loads or even cares about proprietary modules? If you do -then you might have seen something like this: - - $ sudo insmod xxxxxx.ko - loading out-of-tree module taints kernel. - module license 'unspecified' taints kernel. - -You can use a few macros to indicate the license for your module. Some -examples are "GPL", "GPL v2", "GPL and additional rights", "Dual -BSD/GPL", "Dual MIT/GPL", "Dual MPL/GPL" and "Proprietary". They are -defined within -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/module.h). - -To reference what license you’re using a macro is available called -|MODULE_\*-\*-\*_LICENSE|. This and a few other macros describing the -module are illustrated in the below example. - -Passing Command Line Arguments to a Module ------------------------------------------- - -Modules can take command line arguments, but not with the argc/argv you -might be used to. - -To allow arguments to be passed to your module, declare the variables -that will take the values of the command line arguments as global and -then use the |module_\*-\*-\*_param()| macro, (defined in -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/moduleparam.h)) -to set the mechanism up. At runtime, |insmod| will fill the variables -with any command line arguments that are given, like |insmod mymodule.ko -myvariable=5|. The variable declarations and macros should be placed at -the beginning of the module for clarity. The example code should clear -up my admittedly lousy explanation. - -The |module_\*-\*-\*_param()| macro takes 3 arguments: the name of the -variable, its type and permissions for the corresponding file in sysfs. -Integer types can be signed as usual or unsigned. If you’d like to use -arrays of integers or strings see -|module_\*-\*-\*_param_\*-\*-\*_array()| and -|module_\*-\*-\*_param_\*-\*-\*_string()|. - -int myint = 3; module_\*-\*-\*_param(myint, int, 0); - -Arrays are supported too, but things are a bit different now than they -were in the olden days. To keep track of the number of parameters you -need to pass a pointer to a count variable as third parameter. At your -option, you could also ignore the count and pass |NULL| instead. We show -both possibilities here: - -int myintarray\[2\]; module_\*-\*-\*_param_\*-\*-\*_array(myintarray, -int, NULL, 0); /\* not interested in count \*/ - -short myshortarray\[4\]; int count; -module_\*-\*-\*_param_\*-\*-\*_array(myshortarray, short, &count, 0); -/\* put count into "count" variable \*/ - -A good use for this is to have the module variable’s default values set, -like a port or IO address. If the variables contain the default values, -then perform autodetection (explained elsewhere). Otherwise, keep the -current value. This will be made clear later on. - -Lastly, there is a macro function, -|MODULE_\*-\*-\*_PARM_\*-\*-\*_DESC()|, that is used to document -arguments that the module can take. It takes two parameters: a variable -name and a free form string describing that variable. - -It is recommended to experiment with the following code: - - $ sudo insmod hello-5.ko mystring="bebop" myintarray=-1 - $ sudo dmesg -t | tail -7 - myshort is a short integer: 1 - myint is an integer: 420 - mylong is a long integer: 9999 - mystring is a string: bebop - myintarray[0] = -1 - myintarray[1] = 420 - got 1 arguments for myintarray. - - $ sudo rmmod hello-5 - $ sudo dmesg -t | tail -1 - Goodbye, world 5 - - $ sudo insmod hello-5.ko mystring="supercalifragilisticexpialidocious" myintarray=-1,-1 - $ sudo dmesg -t | tail -7 - myshort is a short integer: 1 - myint is an integer: 420 - mylong is a long integer: 9999 - mystring is a string: supercalifragilisticexpialidocious - myintarray[0] = -1 - myintarray[1] = -1 - got 2 arguments for myintarray. - - $ sudo rmmod hello-5 - $ sudo dmesg -t | tail -1 - Goodbye, world 5 - - $ sudo insmod hello-5.ko mylong=hello - insmod: ERROR: could not insert module hello-5.ko: Invalid parameters - -Modules Spanning Multiple Files -------------------------------- - -Sometimes it makes sense to divide a kernel module between several -source files. - -Here is an example of such a kernel module. - -The next file: - -And finally, the makefile: - -This is the complete makefile for all the examples we have seen so far. -The first five lines are nothing special, but for the last example we -will need two lines. First we invent an object name for our combined -module, second we tell |make| what object files are part of that module. - -Building modules for a precompiled kernel ------------------------------------------ - -Obviously, we strongly suggest you to recompile your kernel, so that you -can enable a number of useful debugging features, such as forced module -unloading (|MODULE_\*-\*-\*_FORCE_\*-\*-\*_UNLOAD|): when this option is -enabled, you can force the kernel to unload a module even when it -believes it is unsafe, via a |sudo rmmod -f module| command. This option -can save you a lot of time and a number of reboots during the -development of a module. If you do not want to recompile your kernel -then you should consider running the examples within a test distribution -on a virtual machine. If you mess anything up then you can easily reboot -or restore the virtual machine (VM). - -There are a number of cases in which you may want to load your module -into a precompiled running kernel, such as the ones shipped with common -Linux distributions, or a kernel you have compiled in the past. In -certain circumstances you could require to compile and insert a module -into a running kernel which you are not allowed to recompile, or on a -machine that you prefer not to reboot. If you can’t think of a case that -will force you to use modules for a precompiled kernel you might want to -skip this and treat the rest of this chapter as a big footnote. - -Now, if you just install a kernel source tree, use it to compile your -kernel module and you try to insert your module into the kernel, in most -cases you would obtain an error as follows: - - insmod: ERROR: could not insert module poet.ko: Invalid module format - -Less cryptic information is logged to the systemd journal: - - kernel: poet: disagrees about version of symbol module_*-*-*_layout - -In other words, your kernel refuses to accept your module because -version strings (more precisely, *version magic*, see -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/vermagic.h)) -do not match. Incidentally, version magic strings are stored in the -module object in the form of a static string, starting with |vermagic:|. -Version data are inserted in your module when it is linked against the -`kernel/module.o` file. To inspect version magics and other strings -stored in a given module, issue the command |modinfo module.ko|: - - $ modinfo hello-4.ko - description: A sample driver - author: LKMPG - license: GPL - srcversion: B2AA7FBFCC2C39AED665382 - depends: - retpoline: Y - name: hello_*-*-*_4 - vermagic: 5.4.0-70-generic SMP mod_*-*-*_unload modversions - -To overcome this problem we could resort to the `--force-vermagic` -option, but this solution is potentially unsafe, and unquestionably -unacceptable in production modules. Consequently, we want to compile our -module in an environment which was identical to the one in which our -precompiled kernel was built. How to do this, is the subject of the -remainder of this chapter. - -First of all, make sure that a kernel source tree is available, having -exactly the same version as your current kernel. Then, find the -configuration file which was used to compile your precompiled kernel. -Usually, this is available in your current `boot` directory, under a -name like `config-5.14.x`. You may just want to copy it to your kernel -source tree: |cp /boot/config-‘uname -r‘ .config|. - -Let’s focus again on the previous error message: a closer look at the -version magic strings suggests that, even with two configuration files -which are exactly the same, a slight difference in the version magic -could be possible, and it is sufficient to prevent insertion of the -module into the kernel. That slight difference, namely the custom string -which appears in the module’s version magic and not in the kernel’s one, -is due to a modification with respect to the original, in the makefile -that some distributions include. Then, examine your `Makefile`, and make -sure that the specified version information matches exactly the one used -for your current kernel. For example, your makefile could start as -follows: - - VERSION = 5 - PATCHLEVEL = 14 - SUBLEVEL = 0 - EXTRAVERSION = -rc2 - -In this case, you need to restore the value of symbol **EXTRAVERSION** -to **-rc2**. We suggest keeping a backup copy of the makefile used to -compile your kernel available in `/lib/modules/5.14.0-rc2/build`. A -simple command as following should suffice. - -cp /lib/modules/‘uname -r‘/build/Makefile linux-‘uname -r‘ - -Here |linux-‘uname -r‘| is the Linux kernel source you are attempting to -build. - -Now, please run |make| to update configuration and version headers and -objects: - - $ make - SYNC include/config/auto.conf.cmd - HOSTCC scripts/basic/fixdep - HOSTCC scripts/kconfig/conf.o - HOSTCC scripts/kconfig/confdata.o - HOSTCC scripts/kconfig/expr.o - LEX scripts/kconfig/lexer.lex.c - YACC scripts/kconfig/parser.tab.[ch] - HOSTCC scripts/kconfig/preprocess.o - HOSTCC scripts/kconfig/symbol.o - HOSTCC scripts/kconfig/util.o - HOSTCC scripts/kconfig/lexer.lex.o - HOSTCC scripts/kconfig/parser.tab.o - HOSTLD scripts/kconfig/conf - -If you do not desire to actually compile the kernel, you can interrupt -the build process (CTRL-C) just after the SPLIT line, because at that -time, the files you need are ready. Now you can turn back to the -directory of your module and compile it: It will be built exactly -according to your current kernel settings, and it will load into it -without any errors. - -Preliminaries -============= - -How modules begin and end -------------------------- - -A typical program starts with a |main()| function, executes a series of -instructions, and terminates after completing these instructions. Kernel -modules, however, follow a different pattern. A module always begins -with either the |init_\*-\*-\*_module| function or a function designated -by the |module_\*-\*-\*_init| call. This function acts as the module’s -entry point, informing the kernel of the module’s functionalities and -preparing the kernel to utilize the module’s functions when necessary. -After performing these tasks, the entry function returns, and the module -remains inactive until the kernel requires its code. - -All modules conclude by invoking either |cleanup_\*-\*-\*_module| or a -function specified through the |module_\*-\*-\*_exit| call. This serves -as the module’s exit function, reversing the actions of the entry -function by unregistering the previously registered functionalities. - -It is mandatory for every module to have both an entry and an exit -function. While there are multiple methods to define these functions, -the terms “entry function” and “exit function” are generally used. -However, they may occasionally be referred to as |init_\*-\*-\*_module| -and |cleanup_\*-\*-\*_module|, which are understood to mean the same. - -Functions available to modules ------------------------------- - -Programmers use functions they do not define all the time. A prime -example of this is |printf()|. You use these library functions which are -provided by the standard C library, libc. The definitions for these -functions do not actually enter your program until the linking stage, -which ensures that the code (for |printf()| for example) is available, -and fixes the call instruction to point to that code. - -Kernel modules are different here, too. In the hello world example, you -might have noticed that we used a function, |pr_\*-\*-\*_info()| but did -not include a standard I/O library. That is because modules are object -files whose symbols get resolved upon running |insmod| or |modprobe|. -The definition for the symbols comes from the kernel itself; the only -external functions you can use are the ones provided by the kernel. If -you’re curious about what symbols have been exported by your kernel, -take a look at `/proc/kallsyms`. - -One point to keep in mind is the difference between library functions -and system calls. Library functions are higher level, run completely in -user space and provide a more convenient interface for the programmer to -the functions that do the real work — system calls. System calls run in -kernel mode on the user’s behalf and are provided by the kernel itself. -The library function |printf()| may look like a very general printing -function, but all it really does is format the data into strings and -write the string data using the low-level system call |write()|, which -then sends the data to standard output. - -Would you like to see what system calls are made by |printf()|? It is -easy_ Compile the following program: - -\#include <stdio.h> - -int main(void) printf("hello"); return 0; - -with |gcc -Wall -o hello hello.c|. Run the executable with |strace -./hello|. Are you impressed? Every line you see corresponds to a system -call. [strace](https://strace.io/) is a handy program that gives you -details about what system calls a program is making, including which -call is made, what its arguments are and what it returns. It is an -invaluable tool for figuring out things like what files a program is -trying to access. Towards the end, you will see a line which looks like -|write(1, "hello", 5hello)|. There it is. The face behind the |printf()| -mask. You may not be familiar with write, since most people use library -functions for file I/O (like |fopen|, |fputs|, |fclose|). If that is the -case, try looking at man 2 write. The 2nd man section is devoted to -system calls (like |kill()| and |read()|). The 3rd man section is -devoted to library calls, which you would probably be more familiar with -(like |cosh()| and |random()|). - -You can even write modules to replace the kernel’s system calls, which -we will do shortly. Crackers often make use of this sort of thing for -backdoors or trojans, but you can write your own modules to do more -benign things, like have the kernel write Tee hee, that tickles_ every -time someone tries to delete a file on your system. - -User Space vs Kernel Space --------------------------- - -The kernel primarily manages access to resources, be it a video card, -hard drive, or memory. Programs frequently vie for the same resources. -For instance, as a document is saved, updatedb might commence updating -the locate database. Sessions in editors like vim and processes like -updatedb can simultaneously utilize the hard drive. The kernel’s role is -to maintain order, ensuring that users do not access resources -indiscriminately. - -To manage this, CPUs operate in different modes, each offering varying -levels of system control. The Intel 80386 architecture, for example, -featured four such modes, known as rings. Unix, however, utilizes only -two of these rings: the highest ring (ring 0, also known as “supervisor -mode”, where all actions are permissible) and the lowest ring, referred -to as “user mode”. - -Recall the discussion about library functions vs system calls. -Typically, you use a library function in user mode. The library function -calls one or more system calls, and these system calls execute on the -library function’s behalf, but do so in supervisor mode since they are -part of the kernel itself. Once the system call completes its task, it -returns and execution gets transferred back to user mode. - -Name Space ----------- - -When you write a small C program, you use variables which are convenient -and make sense to the reader. If, on the other hand, you are writing -routines which will be part of a bigger problem, any global variables -you have are part of a community of other peoples’ global variables; -some of the variable names can clash. When a program has lots of global -variables which aren’t meaningful enough to be distinguished, you get -namespace pollution. In large projects, effort must be made to remember -reserved names, and to find ways to develop a scheme for naming unique -variable names and symbols. - -When writing kernel code, even the smallest module will be linked -against the entire kernel, so this is definitely an issue. The best way -to deal with this is to declare all your variables as static and to use -a well-defined prefix for your symbols. By convention, all kernel -prefixes are lowercase. If you do not want to declare everything as -static, another option is to declare a symbol table and register it with -the kernel. We will get to this later. - -The file `/proc/kallsyms` holds all the symbols that the kernel knows -about and which are therefore accessible to your modules since they -share the kernel’s codespace. - -Code space ----------- - -Memory management is a very complicated subject and the majority of -O’Reilly’s [Understanding The Linux -Kernel](https://www.oreilly.com/library/view/understanding-the-linux/0596005652/) -exclusively covers memory management_ We are not setting out to be -experts on memory managements, but we do need to know a couple of facts -to even begin worrying about writing real modules. - -If you have not thought about what a segfault really means, you may be -surprised to hear that pointers do not actually point to memory -locations. Not real ones, anyway. When a process is created, the kernel -sets aside a portion of real physical memory and hands it to the process -to use for its executing code, variables, stack, heap and other things -which a computer scientist would know about. This memory begins with -0x00000000 and extends up to whatever it needs to be. Since the memory -space for any two processes do not overlap, every process that can -access a memory address, say 0xbffff978, would be accessing a different -location in real physical memory_ The processes would be accessing an -index named 0xbffff978 which points to some kind of offset into the -region of memory set aside for that particular process. For the most -part, a process like our Hello, World program can’t access the space of -another process, although there are ways which we will talk about later. - -The kernel has its own space of memory as well. Since a module is code -which can be dynamically inserted and removed in the kernel (as opposed -to a semi-autonomous object), it shares the kernel’s codespace rather -than having its own. Therefore, if your module segfaults, the kernel -segfaults. And if you start writing over data because of an off-by-one -error, then you’re trampling on kernel data (or code). This is even -worse than it sounds, so try your best to be careful. - -It should be noted that the aforementioned discussion applies to any -operating system utilizing a monolithic kernel. This concept differs -slightly from *“building all your modules into the kernel”*, although -the underlying principle is similar. In contrast, there are -microkernels, where modules are allocated their own code space. Two -notable examples of microkernels include the [GNU -Hurd](https://www.gnu.org/software/hurd/) and the [Zircon -kernel](https://fuchsia.dev/fuchsia-src/concepts/kernel) of Google’s -Fuchsia. - -Device Drivers --------------- - -One class of module is the device driver, which provides functionality -for hardware like a serial port. On Unix, each piece of hardware is -represented by a file located in `/dev` named a device file which -provides the means to communicate with the hardware. The device driver -provides the communication on behalf of a user program. So the es1370.ko -sound card device driver might connect the `/dev/sound` device file to -the Ensoniq IS1370 sound card. A userspace program like mp3blaster can -use `/dev/sound` without ever knowing what kind of sound card is -installed. - -Let’s look at some device files. Here are device files which represent -the first three partitions on the primary master IDE hard drive: - - $ ls -l /dev/hda[1-3] - brw-rw---- 1 root disk 3, 1 Jul 5 2000 /dev/hda1 - brw-rw---- 1 root disk 3, 2 Jul 5 2000 /dev/hda2 - brw-rw---- 1 root disk 3, 3 Jul 5 2000 /dev/hda3 - -Notice the column of numbers separated by a comma. The first number is -called the device’s major number. The second number is the minor number. -The major number tells you which driver is used to access the hardware. -Each driver is assigned a unique major number; all device files with the -same major number are controlled by the same driver. All the above major -numbers are 3, because they’re all controlled by the same driver. - -The minor number is used by the driver to distinguish between the -various hardware it controls. Returning to the example above, although -all three devices are handled by the same driver they have unique minor -numbers because the driver sees them as being different pieces of -hardware. - -Devices are divided into two types: character devices and block devices. -The difference is that block devices have a buffer for requests, so they -can choose the best order in which to respond to the requests. This is -important in the case of storage devices, where it is faster to read or -write sectors which are close to each other, rather than those which are -further apart. Another difference is that block devices can only accept -input and return output in blocks (whose size can vary according to the -device), whereas character devices are allowed to use as many or as few -bytes as they like. Most devices in the world are character, because -they don’t need this type of buffering, and they don’t operate with a -fixed block size. You can tell whether a device file is for a block -device or a character device by looking at the first character in the -output of |ls -l|. If it is ‘b’ then it is a block device, and if it is -‘c’ then it is a character device. The devices you see above are block -devices. Here are some character devices (the serial ports): - - crw-rw---- 1 root dial 4, 64 Feb 18 23:34 /dev/ttyS0 - crw-r----- 1 root dial 4, 65 Nov 17 10:26 /dev/ttyS1 - crw-rw---- 1 root dial 4, 66 Jul 5 2000 /dev/ttyS2 - crw-rw---- 1 root dial 4, 67 Jul 5 2000 /dev/ttyS3 - -If you want to see which major numbers have been assigned, you can look -at -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/admin-guide/devices.txt). - -When the system was installed, all of those device files were created by -the |mknod| command. To create a new char device named `coffee` with -major/minor number 12 and 2, simply do |mknod /dev/coffee c 12 2|. You -do not have to put your device files into `/dev`, but it is done by -convention. Linus put his device files in `/dev`, and so should you. -However, when creating a device file for testing purposes, it is -probably OK to place it in your working directory where you compile the -kernel module. Just be sure to put it in the right place when you’re -done writing the device driver. - -A few final points, although implicit in the previous discussion, are -worth stating explicitly for clarity. When a device file is accessed, -the kernel utilizes the file’s major number to identify the appropriate -driver for handling the access. This indicates that the kernel does not -necessarily rely on or need to be aware of the minor number. It is the -driver that concerns itself with the minor number, using it to -differentiate between various pieces of hardware. - -It is important to note that when referring to *“hardware”*, the term is -used in a slightly more abstract sense than just a physical PCI card -that can be held in hand. Consider the following two device files: - - $ ls -l /dev/sda /dev/sdb - brw-rw---- 1 root disk 8, 0 Jan 3 09:02 /dev/sda - brw-rw---- 1 root disk 8, 16 Jan 3 09:02 /dev/sdb - -By now you can look at these two device files and know instantly that -they are block devices and are handled by same driver (block major 8). -Sometimes two device files with the same major but different minor -number can actually represent the same piece of physical hardware. So -just be aware that the word “hardware” in our discussion can mean -something very abstract. - -Character Device drivers -======================== - -The file-\*-\*_operations Structure ------------------------------------ - -The |file_\*-\*-\*_operations| structure is defined in -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/fs.h), -and holds pointers to functions defined by the driver that perform -various operations on the device. Each field of the structure -corresponds to the address of some function defined by the driver to -handle a requested operation. - -For example, every character driver needs to define a function that -reads from the device. The |file_\*-\*-\*_operations| structure holds -the address of the module’s function that performs that operation. Here -is what the definition looks like for kernel 5.4: - -struct file_\*-\*-\*_operations struct module \*owner; loff_\*-\*-\*_t -(\*llseek) (struct file \*, loff_\*-\*-\*_t, int); ssize_\*-\*-\*_t -(\*read) (struct file \*, char _\*-\*-\*_\*-\*-\*_user \*, -size_\*-\*-\*_t, loff_\*-\*-\*_t \*); ssize_\*-\*-\*_t (\*write) (struct -file \*, const char _\*-\*-\*_\*-\*-\*_user \*, size_\*-\*-\*_t, -loff_\*-\*-\*_t \*); ssize_\*-\*-\*_t (\*read_\*-\*-\*_iter) (struct -kiocb \*, struct iov_\*-\*-\*_iter \*); ssize_\*-\*-\*_t -(\*write_\*-\*-\*_iter) (struct kiocb \*, struct iov_\*-\*-\*_iter \*); -int (\*iopoll)(struct kiocb \*kiocb, bool spin); int (\*iterate) (struct -file \*, struct dir_\*-\*-\*_context \*); int -(\*iterate_\*-\*-\*_shared) (struct file \*, struct dir_\*-\*-\*_context -\*); _\*-\*-\*_\*-\*-\*_poll_\*-\*-\*_t (\*poll) (struct file \*, -struct poll_\*-\*-\*_table_\*-\*-\*_struct \*); long -(\*unlocked_\*-\*-\*_ioctl) (struct file \*, unsigned int, unsigned -long); long (\*compat_\*-\*-\*_ioctl) (struct file \*, unsigned int, -unsigned long); int (\*mmap) (struct file \*, struct -vm_\*-\*-\*_area_\*-\*-\*_struct \*); unsigned long -mmap_\*-\*-\*_supported_\*-\*-\*_flags; int (\*open) (struct inode \*, -struct file \*); int (\*flush) (struct file \*, -fl_\*-\*-\*_owner_\*-\*-\*_t id); int (\*release) (struct inode \*, -struct file \*); int (\*fsync) (struct file \*, loff_\*-\*-\*_t, -loff_\*-\*-\*_t, int datasync); int (\*fasync) (int, struct file \*, -int); int (\*lock) (struct file \*, int, struct file_\*-\*-\*_lock \*); -ssize_\*-\*-\*_t (\*sendpage) (struct file \*, struct page \*, int, -size_\*-\*-\*_t, loff_\*-\*-\*_t \*, int); unsigned long -(\*get_\*-\*-\*_unmapped_\*-\*-\*_area)(struct file \*, unsigned long, -unsigned long, unsigned long, unsigned long); int -(\*check_\*-\*-\*_flags)(int); int (\*flock) (struct file \*, int, -struct file_\*-\*-\*_lock \*); ssize_\*-\*-\*_t -(\*splice_\*-\*-\*_write)(struct pipe_\*-\*-\*_inode_\*-\*-\*_info \*, -struct file \*, loff_\*-\*-\*_t \*, size_\*-\*-\*_t, unsigned int); -ssize_\*-\*-\*_t (\*splice_\*-\*-\*_read)(struct file \*, -loff_\*-\*-\*_t \*, struct pipe_\*-\*-\*_inode_\*-\*-\*_info \*, -size_\*-\*-\*_t, unsigned int); int (\*setlease)(struct file \*, long, -struct file_\*-\*-\*_lock \*\*, void \*\*); long (\*fallocate)(struct -file \*file, int mode, loff_\*-\*-\*_t offset, loff_\*-\*-\*_t len); -void (\*show_\*-\*-\*_fdinfo)(struct seq_\*-\*-\*_file \*m, struct file -\*f); ssize_\*-\*-\*_t (\*copy_\*-\*-\*_file_\*-\*-\*_range)(struct file -\*, loff_\*-\*-\*_t, struct file \*, loff_\*-\*-\*_t, size_\*-\*-\*_t, -unsigned int); loff_\*-\*-\*_t -(\*remap_\*-\*-\*_file_\*-\*-\*_range)(struct file \*file_\*-\*-\*_in, -loff_\*-\*-\*_t pos_\*-\*-\*_in, struct file \*file_\*-\*-\*_out, -loff_\*-\*-\*_t pos_\*-\*-\*_out, loff_\*-\*-\*_t len, unsigned int -remap_\*-\*-\*_flags); int (\*fadvise)(struct file \*, loff_\*-\*-\*_t, -loff_\*-\*-\*_t, int); _\*-\*-\*_\*-\*-\*_randomize_\*-\*-\*_layout; - -Some operations are not implemented by a driver. For example, a driver -that handles a video card will not need to read from a directory -structure. The corresponding entries in the |file_\*-\*-\*_operations| -structure should be set to |NULL|. - -There is a gcc extension that makes assigning to this structure more -convenient. You will see it in modern drivers, and may catch you by -surprise. This is what the new way of assigning to the structure looks -like: - -struct file_\*-\*-\*_operations fops = read: device_\*-\*-\*_read, -write: device_\*-\*-\*_write, open: device_\*-\*-\*_open, release: -device_\*-\*-\*_release ; - -However, there is also a C99 way of assigning to elements of a -structure, [designated -initializers](https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html), -and this is definitely preferred over using the GNU extension. You -should use this syntax in case someone wants to port your driver. It -will help with compatibility: - -struct file_\*-\*-\*_operations fops = .read = device_\*-\*-\*_read, -.write = device_\*-\*-\*_write, .open = device_\*-\*-\*_open, .release = -device_\*-\*-\*_release ; - -The meaning is clear, and you should be aware that any member of the -structure which you do not explicitly assign will be initialized to -|NULL| by gcc. - -An instance of |struct file_\*-\*-\*_operations| containing pointers to -functions that are used to implement |read|, |write|, |open|, … system -calls is commonly named |fops|. - -Since Linux v3.14, the read, write and seek operations are guaranteed -for thread-safe by using the |f_\*-\*-\*_pos| specific lock, which makes -the file position update to become the mutual exclusion. So, we can -safely implement those operations without unnecessary locking. - -Additionally, since Linux v5.6, the |proc_\*-\*-\*_ops| structure was -introduced to replace the use of the |file_\*-\*-\*_operations| -structure when registering proc handlers. See more information in the -7.1 -section. - -The file structure ------------------- - -Each device is represented in the kernel by a file structure, which is -defined in -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/fs.h). -Be aware that a file is a kernel level structure and never appears in a -user space program. It is not the same thing as a |FILE|, which is -defined by glibc and would never appear in a kernel space function. -Also, its name is a bit misleading; it represents an abstract open -‘file’, not a file on a disk, which is represented by a structure named -|inode|. - -An instance of struct file is commonly named |filp|. You’ll also see it -referred to as a struct file object. Resist the temptation. - -Go ahead and look at the definition of file. Most of the entries you -see, like struct dentry are not used by device drivers, and you can -ignore them. This is because drivers do not fill file directly; they -only use structures contained in file which are created elsewhere. - -Registering A Device --------------------- - -As discussed earlier, char devices are accessed through device files, -usually located in `/dev`. This is by convention. When writing a driver, -it is OK to put the device file in your current directory. Just make -sure you place it in `/dev` for a production driver. The major number -tells you which driver handles which device file. The minor number is -used only by the driver itself to differentiate which device it is -operating on, just in case the driver handles more than one device. - -Adding a driver to your system means registering it with the kernel. -This is synonymous with assigning it a major number during the module’s -initialization. You do this by using the |register_\*-\*-\*_chrdev| -function, defined by -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/fs.h). - -int register_\*-\*-\*_chrdev(unsigned int major, const char \*name, -struct file_\*-\*-\*_operations \*fops); - -Where unsigned int major is the major number you want to request, |const -char \*name| is the name of the device as it will appear in -`/proc/devices` and |struct file_\*-\*-\*_operations \*fops| is a -pointer to the |file_\*-\*-\*_operations| table for your driver. A -negative return value means the registration failed. Note that we didn’t -pass the minor number to |register_\*-\*-\*_chrdev|. That is because the -kernel doesn’t care about the minor number; only our driver uses it. - -Now the question is, how do you get a major number without hijacking one -that’s already in use? The easiest way would be to look through -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/admin-guide/devices.txt) -and pick an unused one. That is a bad way of doing things because you -will never be sure if the number you picked will be assigned later. The -answer is that you can ask the kernel to assign you a dynamic major -number. - -If you pass a major number of 0 to |register_\*-\*-\*_chrdev|, the -return value will be the dynamically allocated major number. The -downside is that you can not make a device file in advance, since you do -not know what the major number will be. There are a couple of ways to do -this. First, the driver itself can print the newly assigned number and -we can make the device file by hand. Second, the newly registered device -will have an entry in `/proc/devices`, and we can either make the device -file by hand or write a shell script to read the file in and make the -device file. The third method is that we can have our driver make the -device file using the |device_\*-\*-\*_create| function after a -successful registration and |device_\*-\*-\*_destroy| during the call to -|cleanup_\*-\*-\*_module|. - -However, |register_\*-\*-\*_chrdev()| would occupy a range of minor -numbers associated with the given major. The recommended way to reduce -waste for char device registration is using cdev interface. - -The newer interface completes the char device registration in two -distinct steps. First, we should register a range of device numbers, -which can be completed with |register_\*-\*-\*_chrdev_\*-\*-\*_region| -or |alloc_\*-\*-\*_chrdev_\*-\*-\*_region|. - -int register_\*-\*-\*_chrdev_\*-\*-\*_region(dev_\*-\*-\*_t from, -unsigned count, const char \*name); int -alloc_\*-\*-\*_chrdev_\*-\*-\*_region(dev_\*-\*-\*_t \*dev, unsigned -baseminor, unsigned count, const char \*name); - -The choice between two different functions depends on whether you know -the major numbers for your device. Using -|register_\*-\*-\*_chrdev_\*-\*-\*_region| if you know the device major -number and |alloc_\*-\*-\*_chrdev_\*-\*-\*_region| if you would like to -allocate a dynamically-allocated major number. - -Second, we should initialize the data structure |struct cdev| for our -char device and associate it with the device numbers. To initialize the -|struct cdev|, we can achieve by the similar sequence of the following -codes. - -struct cdev \*my_\*-\*-\*_dev = cdev_\*-\*-\*_alloc(); -my_\*-\*-\*_cdev->ops = &my_\*-\*-\*_fops; - -However, the common usage pattern will embed the |struct cdev| within a -device-specific structure of your own. In this case, we’ll need -|cdev_\*-\*-\*_init| for the initialization. - -void cdev_\*-\*-\*_init(struct cdev \*cdev, const struct -file_\*-\*-\*_operations \*fops); - -Once we finish the initialization, we can add the char device to the -system by using the |cdev_\*-\*-\*_add|. - -int cdev_\*-\*-\*_add(struct cdev \*p, dev_\*-\*-\*_t dev, unsigned -count); - -To find an example using the interface, you can see `ioctl.c` described -in section -9. - -Unregistering A Device ----------------------- - -We can not allow the kernel module to be |rmmod|’ed whenever root feels -like it. If the device file is opened by a process and then we remove -the kernel module, using the file would cause a call to the memory -location where the appropriate function (read/write) used to be. If we -are lucky, no other code was loaded there, and we’ll get an ugly error -message. If we are unlucky, another kernel module was loaded into the -same location, which means a jump into the middle of another function -within the kernel. The results of this would be impossible to predict, -but they can not be very positive. - -Normally, when you do not want to allow something, you return an error -code (a negative number) from the function which is supposed to do it. -With |cleanup_\*-\*-\*_module| that’s impossible because it is a void -function. However, there is a counter which keeps track of how many -processes are using your module. You can see what its value is by -looking at the 3rd field with the command |cat /proc/modules| or |sudo -lsmod|. If this number isn’t zero, |rmmod| will fail. Note that you do -not have to check the counter within |cleanup_\*-\*-\*_module| because -the check will be performed for you by the system call -|sys_\*-\*-\*_delete_\*-\*-\*_module|, defined in -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/syscalls.h). -You should not use this counter directly, but there are functions -defined in -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/module.h) -which let you increase, decrease and display this counter: - -- |try_\*-\*-\*_module_\*-\*-\*_get(THIS_\*-\*-\*_MODULE)|: Increment - the reference count of current module. - -- |module_\*-\*-\*_put(THIS_\*-\*-\*_MODULE)|: Decrement the reference - count of current module. - -- |module_\*-\*-\*_refcount(THIS_\*-\*-\*_MODULE)|: Return the value - of reference count of current module. - -It is important to keep the counter accurate; if you ever do lose track -of the correct usage count, you will never be able to unload the module; -it’s now reboot time, boys and girls. This is bound to happen to you -sooner or later during a module’s development. - -chardev.c ---------- - -The next code sample creates a char driver named `chardev`. You can dump -its device file. - -cat /proc/devices - -(or open the file with a program) and the driver will put the number of -times the device file has been read from into the file. We do not -support writing to the file (like |echo "hi" > /dev/hello|), but -catch these attempts and tell the user that the operation is not -supported. Don’t worry if you don’t see what we do with the data we read -into the buffer; we don’t do much with it. We simply read in the data -and print a message acknowledging that we received it. - -In the multiple-threaded environment, without any protection, concurrent -access to the same memory may lead to the race condition, and will not -preserve the performance. In the kernel module, this problem may happen -due to multiple instances accessing the shared resources. Therefore, a -solution is to enforce the exclusive access. We use atomic -Compare-And-Swap (CAS) to maintain the states, -|CDEV_\*-\*-\*_NOT_\*-\*-\*_USED| and -|CDEV_\*-\*-\*_EXCLUSIVE_\*-\*-\*_OPEN|, to determine whether the file -is currently opened by someone or not. CAS compares the contents of a -memory location with the expected value and, only if they are the same, -modifies the contents of that memory location to the desired value. See -more concurrency details in the -12 -section. - -Writing Modules for Multiple Kernel Versions --------------------------------------------- - -The system calls, which are the major interface the kernel shows to the -processes, generally stay the same across versions. A new system call -may be added, but usually the old ones will behave exactly like they -used to. This is necessary for backward compatibility – a new kernel -version is not supposed to break regular processes. In most cases, the -device files will also remain the same. On the other hand, the internal -interfaces within the kernel can and do change between versions. - -There are differences between different kernel versions, and if you want -to support multiple kernel versions, you will find yourself having to -code conditional compilation directives. The way to do this to compare -the macro |LINUX_\*-\*-\*_VERSION_\*-\*-\*_CODE| to the macro -|KERNEL_\*-\*-\*_VERSION|. In version `a.b.c` of the kernel, the value -of this macro would be 216*a* + 28*b* + *c*. - -The /proc File System -===================== - -In Linux, there is an additional mechanism for the kernel and kernel -modules to send information to processes — the `/proc` file system. -Originally designed to allow easy access to information about processes -(hence the name), it is now used by every bit of the kernel which has -something interesting to report, such as `/proc/modules` which provides -the list of modules and `/proc/meminfo` which gathers memory usage -statistics. - -The method to use the proc file system is very similar to the one used -with device drivers — a structure is created with all the information -needed for the `/proc` file, including pointers to any handler functions -(in our case there is only one, the one called when somebody attempts to -read from the `/proc` file). Then, |init_\*-\*-\*_module| registers the -structure with the kernel and |cleanup_\*-\*-\*_module| unregisters it. - -Normal file systems are located on a disk, rather than just in memory -(which is where `/proc` is), and in that case the index-node (inode for -short) number is a pointer to a disk location where the file’s inode is -located. The inode contains information about the file, for example the -file’s permissions, together with a pointer to the disk location or -locations where the file’s data can be found. - -Because we don’t get called when the file is opened or closed, there’s -nowhere for us to put |try_\*-\*-\*_module_\*-\*-\*_get| and -|module_\*-\*-\*_put| in this module, and if the file is opened and then -the module is removed, there’s no way to avoid the consequences. - -Here a simple example showing how to use a `/proc` file. This is the -HelloWorld for the `/proc` filesystem. There are three parts: create the -file `/proc/helloworld` in the function |init_\*-\*-\*_module|, return a -value (and a buffer) when the file `/proc/helloworld` is read in the -callback function |procfile_\*-\*-\*_read|, and delete the file -`/proc/helloworld` in the function |cleanup_\*-\*-\*_module|. - -The `/proc/helloworld` is created when the module is loaded with the -function |proc_\*-\*-\*_create|. The return value is a pointer to -|struct proc_\*-\*-\*_dir_\*-\*-\*_entry|, and it will be used to -configure the file `/proc/helloworld` (for example, the owner of this -file). A null return value means that the creation has failed. - -Every time the file `/proc/helloworld` is read, the function -|procfile_\*-\*-\*_read| is called. Two parameters of this function are -very important: the buffer (the second parameter) and the offset (the -fourth one). The content of the buffer will be returned to the -application which read it (for example the |cat| command). The offset is -the current position in the file. If the return value of the function is -not null, then this function is called again. So be careful with this -function, if it never returns zero, the read function is called -endlessly. - - $ cat /proc/helloworld - HelloWorld_ - -The proc-\*-\*_ops Structure ----------------------------- - -The |proc_\*-\*-\*_ops| structure is defined in -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/proc\_*-*-*_fs.h) -in Linux v5.6+. In older kernels, it used |file_\*-\*-\*_operations| for -custom hooks in `/proc` file system, but it contains some members that -are unnecessary in VFS, and every time VFS expands -|file_\*-\*-\*_operations| set, `/proc` code comes bloated. On the other -hand, not only the space, but also some operations were saved by this -structure to improve its performance. For example, the file which never -disappears in `/proc` can set the |proc_\*-\*-\*_flag| as -|PROC_\*-\*-\*_ENTRY_\*-\*-\*_PERMANENT| to save 2 atomic ops, 1 -allocation, 1 free in per open/read/close sequence. - -Read and Write a /proc File ---------------------------- - -We have seen a very simple example for a `/proc` file where we only read -the file `/proc/helloworld`. It is also possible to write in a `/proc` -file. It works the same way as read, a function is called when the -`/proc` file is written. But there is a little difference with read, -data comes from user, so you have to import data from user space to -kernel space (with |copy_\*-\*-\*_from_\*-\*-\*_user| or -|get_\*-\*-\*_user|) - -The reason for |copy_\*-\*-\*_from_\*-\*-\*_user| or |get_\*-\*-\*_user| -is that Linux memory (on Intel architecture, it may be different under -some other processors) is segmented. This means that a pointer, by -itself, does not reference a unique location in memory, only a location -in a memory segment, and you need to know which memory segment it is to -be able to use it. There is one memory segment for the kernel, and one -for each of the processes. - -The only memory segment accessible to a process is its own, so when -writing regular programs to run as processes, there is no need to worry -about segments. When you write a kernel module, normally you want to -access the kernel memory segment, which is handled automatically by the -system. However, when the content of a memory buffer needs to be passed -between the currently running process and the kernel, the kernel -function receives a pointer to the memory buffer which is in the process -segment. The |put_\*-\*-\*_user| and |get_\*-\*-\*_user| macros allow -you to access that memory. These functions handle only one character, -you can handle several characters with |copy_\*-\*-\*_to_\*-\*-\*_user| -and |copy_\*-\*-\*_from_\*-\*-\*_user|. As the buffer (in read or write -function) is in kernel space, for write function you need to import data -because it comes from user space, but not for the read function because -data is already in kernel space. - -Manage /proc file with standard filesystem ------------------------------------------- - -We have seen how to read and write a `/proc` file with the `/proc` -interface. But it is also possible to manage `/proc` file with inodes. -The main concern is to use advanced functions, like permissions. - -In Linux, there is a standard mechanism for file system registration. -Since every file system has to have its own functions to handle inode -and file operations, there is a special structure to hold pointers to -all those functions, |struct inode_\*-\*-\*_operations|, which includes -a pointer to |struct proc_\*-\*-\*_ops|. - -The difference between file and inode operations is that file operations -deal with the file itself whereas inode operations deal with ways of -referencing the file, such as creating links to it. - -In `/proc`, whenever we register a new file, we’re allowed to specify -which |struct inode_\*-\*-\*_operations| will be used to access to it. -This is the mechanism we use, a |struct inode_\*-\*-\*_operations| which -includes a pointer to a |struct proc_\*-\*-\*_ops| which includes -pointers to our |procfs_\*-\*-\*_read| and |procfs_\*-\*-\*_write| -functions. - -Another interesting point here is the |module_\*-\*-\*_permission| -function. This function is called whenever a process tries to do -something with the `/proc` file, and it can decide whether to allow -access or not. Right now it is only based on the operation and the uid -of the current user (as available in current, a pointer to a structure -which includes information on the currently running process), but it -could be based on anything we like, such as what other processes are -doing with the same file, the time of day, or the last input we -received. - -It is important to note that the standard roles of read and write are -reversed in the kernel. Read functions are used for output, whereas -write functions are used for input. The reason for that is that read and -write refer to the user’s point of view — if a process reads something -from the kernel, then the kernel needs to output it, and if a process -writes something to the kernel, then the kernel receives it as input. - -Still hungry for procfs examples? Well, first of all keep in mind, there -are rumors around, claiming that procfs is on its way out, consider -using `sysfs` instead. Consider using this mechanism, in case you want -to document something kernel related yourself. - -Manage /proc file with seq-\*-\*_file -------------------------------------- - -As we have seen, writing a `/proc` file may be quite “complex”. So to -help people writing `/proc` file, there is an API named -|seq_\*-\*-\*_file| that helps formatting a `/proc` file for output. It -is based on sequence, which is composed of 3 functions: |start()|, -|next()|, and |stop()|. The |seq_\*-\*-\*_file| API starts a sequence -when a user read the `/proc` file. - -A sequence begins with the call of the function |start()|. If the return -is a non |NULL| value, the function |next()| is called; otherwise, the -|stop()| function is called directly. This function is an iterator, the -goal is to go through all the data. Each time |next()| is called, the -function |show()| is also called. It writes data values in the buffer -read by the user. The function |next()| is called until it returns -|NULL|. The sequence ends when |next()| returns |NULL|, then the -function |stop()| is called. - -BE CAREFUL: when a sequence is finished, another one starts. That means -that at the end of function |stop()|, the function |start()| is called -again. This loop finishes when the function |start()| returns |NULL|. -You can see a scheme of this in the -Figure [img:seqfile]. - -The |seq_\*-\*-\*_file| provides basic functions for -|proc_\*-\*-\*_ops|, such as |seq_\*-\*-\*_read|, |seq_\*-\*-\*_lseek|, -and some others. But nothing to write in the `/proc` file. Of course, -you can still use the same way as in the previous example. - -If you want more information, you can read this web page: - -- - -- - -You can also read the code of -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/seq\_*-*-*_file.c) -in the linux kernel. - -sysfs: Interacting with your module -=================================== - -*sysfs* allows you to interact with the running kernel from userspace by -reading or setting variables inside of modules. This can be useful for -debugging purposes, or just as an interface for applications or scripts. -You can find sysfs directories and files under the `/sys` directory on -your system. - -ls -l /sys - -Attributes can be exported for kobjects in the form of regular files in -the filesystem. Sysfs forwards file I/O operations to methods defined -for the attributes, providing a means to read and write kernel -attributes. - -An attribute definition in simply: - -struct attribute char \*name; struct module \*owner; umode_\*-\*-\*_t -mode; ; - -int sysfs_\*-\*-\*_create_\*-\*-\*_file(struct kobject \* kobj, const -struct attribute \* attr); void -sysfs_\*-\*-\*_remove_\*-\*-\*_file(struct kobject \* kobj, const struct -attribute \* attr); - -For example, the driver model defines |struct device_\*-\*-\*_attribute| -like: - -struct device_\*-\*-\*_attribute struct attribute attr; ssize_\*-\*-\*_t -(\*show)(struct device \*dev, struct device_\*-\*-\*_attribute \*attr, -char \*buf); ssize_\*-\*-\*_t (\*store)(struct device \*dev, struct -device_\*-\*-\*_attribute \*attr, const char \*buf, size_\*-\*-\*_t -count); ; - -int device_\*-\*-\*_create_\*-\*-\*_file(struct device \*, const struct -device_\*-\*-\*_attribute \*); void -device_\*-\*-\*_remove_\*-\*-\*_file(struct device \*, const struct -device_\*-\*-\*_attribute \*); - -To read or write attributes, |show()| or |store()| method must be -specified when declaring the attribute. For the common cases -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/sysfs.h) -provides convenience macros (|_\*-\*-\*_\*-\*-\*_ATTR|, -|_\*-\*-\*_\*-\*-\*_ATTR_\*-\*-\*_RO|, -|_\*-\*-\*_\*-\*-\*_ATTR_\*-\*-\*_WO|, etc.) to make defining -attributes easier as well as making code more concise and readable. - -An example of a hello world module which includes the creation of a -variable accessible via sysfs is given below. - -Make and install the module: - -make sudo insmod hello-sysfs.ko - -Check that it exists: - -sudo lsmod | grep hello_\*-\*-\*_sysfs - -What is the current value of |myvariable| ? - -sudo cat /sys/kernel/mymodule/myvariable - -Set the value of |myvariable| and check that it changed. - -echo "32" | sudo tee /sys/kernel/mymodule/myvariable sudo cat -/sys/kernel/mymodule/myvariable - -Finally, remove the test module: - -sudo rmmod hello_\*-\*-\*_sysfs - -In the above case, we use a simple kobject to create a directory under -sysfs, and communicate with its attributes. Since Linux v2.6.0, the -|kobject| structure made its appearance. It was initially meant as a -simple way of unifying kernel code which manages reference counted -objects. After a bit of mission creep, it is now the glue that holds -much of the device model and its sysfs interface together. For more -information about kobject and sysfs, see -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/driver-api/driver-model/driver.rst) -and . - -Talking To Device Files -======================= - -Device files are supposed to represent physical devices. Most physical -devices are used for output as well as input, so there has to be some -mechanism for device drivers in the kernel to get the output to send to -the device from processes. This is done by opening the device file for -output and writing to it, just like writing to a file. In the following -example, this is implemented by |device_\*-\*-\*_write|. - -This is not always enough. Imagine you had a serial port connected to a -modem (even if you have an internal modem, it is still implemented from -the CPU’s perspective as a serial port connected to a modem, so you -don’t have to tax your imagination too hard). The natural thing to do -would be to use the device file to write things to the modem (either -modem commands or data to be sent through the phone line) and read -things from the modem (either responses for commands or the data -received through the phone line). However, this leaves open the question -of what to do when you need to talk to the serial port itself, for -example to configure the rate at which data is sent and received. - -The answer in Unix is to use a special function called |ioctl| (short -for Input Output ConTroL). Every device can have its own |ioctl| -commands, which can be read ioctl’s (to send information from a process -to the kernel), write ioctl’s (to return information to a process), both -or neither. Notice here the roles of read and write are reversed again, -so in ioctl’s read is to send information to the kernel and write is to -receive information from the kernel. - -The ioctl function is called with three parameters: the file descriptor -of the appropriate device file, the ioctl number, and a parameter, which -is of type long so you can use a cast to use it to pass anything. You -will not be able to pass a structure this way, but you will be able to -pass a pointer to the structure. Here is an example: - -You can see there is an argument called |cmd| in -|test_\*-\*-\*_ioctl_\*-\*-\*_ioctl()| function. It is the ioctl number. -The ioctl number encodes the major device number, the type of the ioctl, -the command, and the type of the parameter. This ioctl number is usually -created by a macro call (|_\*-\*-\*_IO|, |_\*-\*-\*_IOR|, -|_\*-\*-\*_IOW| or |_\*-\*-\*_IOWR| — depending on the type) in a header -file. This header file should then be included both by the programs -which will use ioctl (so they can generate the appropriate ioctl’s) and -by the kernel module (so it can understand it). In the example below, -the header file is `chardev.h` and the program which uses it is -`userspace_*-*-*_ioctl.c`. - -If you want to use ioctls in your own kernel modules, it is best to -receive an official ioctl assignment, so if you accidentally get -somebody else’s ioctls, or if they get yours, you’ll know something is -wrong. For more information, consult the kernel source tree at -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/userspace-api/ioctl/ioctl-number.rst). - -Also, we need to be careful that concurrent access to the shared -resources will lead to the race condition. The solution is using atomic -Compare-And-Swap (CAS), which we mentioned at -6.5 -section, to enforce the exclusive access. - -System Calls -============ - -So far, the only thing we’ve done was to use well defined kernel -mechanisms to register `/proc` files and device handlers. This is fine -if you want to do something the kernel programmers thought you’d want, -such as write a device driver. But what if you want to do something -unusual, to change the behavior of the system in some way? Then, you are -mostly on your own. - -Should one choose not to use a virtual machine, kernel programming can -become risky. For example, while writing the code below, the |open()| -system call was inadvertently disrupted. This resulted in an inability -to open any files, run programs, or shut down the system, necessitating -a restart of the virtual machine. Fortunately, no critical files were -lost in this instance. However, if such modifications were made on a -live, mission-critical system, the consequences could be severe. To -mitigate the risk of file loss, even in a test environment, it is -advised to execute |sync| right before using |insmod| and |rmmod|. - -Forget about `/proc` files, forget about device files. They are just -minor details. Minutiae in the vast expanse of the universe. The real -process to kernel communication mechanism, the one used by all -processes, is *system calls*. When a process requests a service from the -kernel (such as opening a file, forking to a new process, or requesting -more memory), this is the mechanism used. If you want to change the -behaviour of the kernel in interesting ways, this is the place to do it. -By the way, if you want to see which system calls a program uses, run -|strace <arguments>|. - -In general, a process is not supposed to be able to access the kernel. -It can not access kernel memory and it can’t call kernel functions. The -hardware of the CPU enforces this (that is the reason why it is called -“protected mode” or “page protection”). - -System calls are an exception to this general rule. What happens is that -the process fills the registers with the appropriate values and then -calls a special instruction which jumps to a previously defined location -in the kernel (of course, that location is readable by user processes, -it is not writable by them). Under Intel CPUs, this is done by means of -interrupt 0x80. The hardware knows that once you jump to this location, -you are no longer running in restricted user mode, but as the operating -system kernel — and therefore you’re allowed to do whatever you want. - -The location in the kernel a process can jump to is called -`system_*-*-*_call`. The procedure at that location checks the system -call number, which tells the kernel what service the process requested. -Then, it looks at the table of system calls -(|sys_\*-\*-\*_call_\*-\*-\*_table|) to see the address of the kernel -function to call. Then it calls the function, and after it returns, does -a few system checks and then return back to the process (or to a -different process, if the process time ran out). If you want to read -this code, it is at the source file -`arch/$(architecture)/kernel/entry.S`, after the line -|ENTRY(system_\*-\*-\*_call)|. - -So, if we want to change the way a certain system call works, what we -need to do is to write our own function to implement it (usually by -adding a bit of our own code, and then calling the original function) -and then change the pointer at |sys_\*-\*-\*_call_\*-\*-\*_table| to -point to our function. Because we might be removed later and we don’t -want to leave the system in an unstable state, it’s important for -|cleanup_\*-\*-\*_module| to restore the table to its original state. - -To modify the content of |sys_\*-\*-\*_call_\*-\*-\*_table|, we need to -consider the control register. A control register is a processor -register that changes or controls the general behavior of the CPU. For -x86 architecture, the `cr0` register has various control flags that -modify the basic operation of the processor. The `WP` flag in `cr0` -stands for write protection. Once the `WP` flag is set, the processor -disallows further write attempts to the read-only sections Therefore, we -must disable the `WP` flag before modifying -|sys_\*-\*-\*_call_\*-\*-\*_table|. Since Linux v5.3, the -|write_\*-\*-\*_cr0| function cannot be used because of the sensitive -`cr0` bits pinned by the security issue, the attacker may write into CPU -control registers to disable CPU protections like write protection. As a -result, we have to provide the custom assembly routine to bypass it. - -However, |sys_\*-\*-\*_call_\*-\*-\*_table| symbol is unexported to -prevent misuse. But there have few ways to get the symbol, manual symbol -lookup and |kallsyms_\*-\*-\*_lookup_\*-\*-\*_name|. Here we use both -depend on the kernel version. - -Because of the *control-flow integrity*, which is a technique to prevent -the redirect execution code from the attacker, for making sure that the -indirect calls go to the expected addresses and the return addresses are -not changed. Since Linux v5.7, the kernel patched the series of -*control-flow enforcement* (CET) for x86, and some configurations of -GCC, like GCC versions 9 and 10 in Ubuntu Linux, will add with CET (the -`-fcf-protection` option) in the kernel by default. Using that GCC to -compile the kernel with retpoline off may result in CET being enabled in -the kernel. You can use the following command to check out the -`-fcf-protection` option is enabled or not: - - $ gcc -v -Q -O2 --help=target | grep protection - Using built-in specs. - COLLECT_*-*-*_GCC=gcc - COLLECT_*-*-*_LTO_*-*-*_WRAPPER=/usr/lib/gcc/x86_*-*-*_64-linux-gnu/9/lto-wrapper - ... - gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) - COLLECT_*-*-*_GCC_*-*-*_OPTIONS='-v' '-Q' '-O2' '--help=target' '-mtune=generic' '-march=x86-64' - /usr/lib/gcc/x86_*-*-*_64-linux-gnu/9/cc1 -v ... -fcf-protection ... - GNU C17 (Ubuntu 9.3.0-17ubuntu1~20.04) version 9.3.0 (x86_*-*-*_64-linux-gnu) - ... - -But CET should not be enabled in the kernel, it may break the Kprobes -and bpf. Consequently, CET is disabled since v5.11. To guarantee the -manual symbol lookup worked, we only use up to v5.4. - -Unfortunately, since Linux v5.7 |kallsyms_\*-\*-\*_lookup_\*-\*-\*_name| -is also unexported, it needs certain trick to get the address of -|kallsyms_\*-\*-\*_lookup_\*-\*-\*_name|. If |CONFIG_\*-\*-\*_KPROBES| -is enabled, we can facilitate the retrieval of function addresses by -means of Kprobes to dynamically break into the specific kernel routine. -Kprobes inserts a breakpoint at the entry of function by replacing the -first bytes of the probed instruction. When a CPU hits the breakpoint, -registers are stored, and the control will pass to Kprobes. It passes -the addresses of the saved registers and the Kprobe struct to the -handler you defined, then executes it. Kprobes can be registered by -symbol name or address. Within the symbol name, the address will be -handled by the kernel. - -Otherwise, specify the address of |sys_\*-\*-\*_call_\*-\*-\*_table| -from `/proc/kallsyms` and `/boot/System.map` into |sym| parameter. -Following is the sample usage for `/proc/kallsyms`: - - $ sudo grep sys_*-*-*_call_*-*-*_table /proc/kallsyms - ffffffff82000280 R x32_*-*-*_sys_*-*-*_call_*-*-*_table - ffffffff820013a0 R sys_*-*-*_call_*-*-*_table - ffffffff820023e0 R ia32_*-*-*_sys_*-*-*_call_*-*-*_table - $ sudo insmod syscall-steal.ko sym=0xffffffff820013a0 - -Using the address from `/boot/System.map`, be careful about `KASLR` -(Kernel Address Space Layout Randomization). `KASLR` may randomize the -address of kernel code and data at every boot time, such as the static -address listed in `/boot/System.map` will offset by some entropy. The -purpose of `KASLR` is to protect the kernel space from the attacker. -Without `KASLR`, the attacker may find the target address in the fixed -address easily. Then the attacker can use return-oriented programming to -insert some malicious codes to execute or receive the target data by a -tampered pointer. `KASLR` mitigates these kinds of attacks because the -attacker cannot immediately know the target address, but a brute-force -attack can still work. If the address of a symbol in `/proc/kallsyms` is -different from the address in `/boot/System.map`, `KASLR` is enabled -with the kernel, which your system running on. - - $ grep GRUB_*-*-*_CMDLINE_*-*-*_LINUX_*-*-*_DEFAULT /etc/default/grub - GRUB_*-*-*_CMDLINE_*-*-*_LINUX_*-*-*_DEFAULT="quiet splash" - $ sudo grep sys_*-*-*_call_*-*-*_table /boot/System.map-$(uname -r) - ffffffff82000300 R sys_*-*-*_call_*-*-*_table - $ sudo grep sys_*-*-*_call_*-*-*_table /proc/kallsyms - ffffffff820013a0 R sys_*-*-*_call_*-*-*_table - # Reboot - $ sudo grep sys_*-*-*_call_*-*-*_table /boot/System.map-$(uname -r) - ffffffff82000300 R sys_*-*-*_call_*-*-*_table - $ sudo grep sys_*-*-*_call_*-*-*_table /proc/kallsyms - ffffffff86400300 R sys_*-*-*_call_*-*-*_table - -If `KASLR` is enabled, we have to take care of the address from -`/proc/kallsyms` each time we reboot the machine. In order to use the -address from `/boot/System.map`, make sure that `KASLR` is disabled. You -can add the `nokaslr` for disabling `KASLR` in next booting time: - - $ grep GRUB_*-*-*_CMDLINE_*-*-*_LINUX_*-*-*_DEFAULT /etc/default/grub - GRUB_*-*-*_CMDLINE_*-*-*_LINUX_*-*-*_DEFAULT="quiet splash" - $ sudo perl -i -pe 'm/quiet/ and s//quiet nokaslr/' /etc/default/grub - $ grep quiet /etc/default/grub - GRUB_*-*-*_CMDLINE_*-*-*_LINUX_*-*-*_DEFAULT="quiet nokaslr splash" - $ sudo update-grub - -For more information, check out the following: - -- [Cook: Security things in Linux - v5.3](https://lwn.net/Articles/804849/) - -- [Unexporting the system call table](https://lwn.net/Articles/12211/) - -- [Control-flow integrity for the - kernel](https://lwn.net/Articles/810077/) - -- [Unexporting - kallsyms-\*-\*_lookup-\*-\*_name()](https://lwn.net/Articles/813350/) - -- [Kernel Probes - (Kprobes)](https://www.kernel.org/doc/Documentation/kprobes.txt) - -- [Kernel address space layout - randomization](https://lwn.net/Articles/569635/) - -The source code here is an example of such a kernel module. We want to -“spy” on a certain user, and to |pr_\*-\*-\*_info()| a message whenever -that user opens a file. Towards this end, we replace the system call to -open a file with our own function, called -|our_\*-\*-\*_sys_\*-\*-\*_openat|. This function checks the uid (user’s -id) of the current process, and if it is equal to the uid we spy on, it -calls |pr_\*-\*-\*_info()| to display the name of the file to be opened. -Then, either way, it calls the original |openat()| function with the -same parameters, to actually open the file. - -The |init_\*-\*-\*_module| function replaces the appropriate location in -|sys_\*-\*-\*_call_\*-\*-\*_table| and keeps the original pointer in a -variable. The |cleanup_\*-\*-\*_module| function uses that variable to -restore everything back to normal. This approach is dangerous, because -of the possibility of two kernel modules changing the same system call. -Imagine we have two kernel modules, A and B. A’s openat system call will -be |A_\*-\*-\*_openat| and B’s will be |B_\*-\*-\*_openat|. Now, when A -is inserted into the kernel, the system call is replaced with -|A_\*-\*-\*_openat|, which will call the original |sys_\*-\*-\*_openat| -when it is done. Next, B is inserted into the kernel, which replaces the -system call with |B_\*-\*-\*_openat|, which will call what it thinks is -the original system call, |A_\*-\*-\*_openat|, when it’s done. - -Now, if B is removed first, everything will be well — it will simply -restore the system call to |A_\*-\*-\*_openat|, which calls the -original. However, if A is removed and then B is removed, the system -will crash. A’s removal will restore the system call to the original, -|sys_\*-\*-\*_openat|, cutting B out of the loop. Then, when B is -removed, it will restore the system call to what it thinks is the -original, |A_\*-\*-\*_openat|, which is no longer in memory. At first -glance, it appears we could solve this particular problem by checking if -the system call is equal to our open function and if so not changing it -at all (so that B won’t change the system call when it is removed), but -that will cause an even worse problem. When A is removed, it sees that -the system call was changed to |B_\*-\*-\*_openat| so that it is no -longer pointing to |A_\*-\*-\*_openat|, so it will not restore it to -|sys_\*-\*-\*_openat| before it is removed from memory. Unfortunately, -|B_\*-\*-\*_openat| will still try to call |A_\*-\*-\*_openat| which is -no longer there, so that even without removing B the system would crash. - -For x86 architecture, the system call table cannot be used to invoke a -system call after commit -[1e3ad78](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e3ad78334a69b36e107232e337f9d693dcc9df2) -since v6.9. This commit has been backported to long term stable kernels, -like v5.15.154+, v6.1.85+, v6.6.26+ and v6.8.5+, see this -[answer](https://stackoverflow.com/a/78607015) for more details. In this -case, thanks to Kprobes, a hook can be used instead on the system call -entry to intercept the system call. - -Note that all the related problems make syscall stealing unfeasible for -production use. In order to keep people from doing potential harmful -things |sys_\*-\*-\*_call_\*-\*-\*_table| is no longer exported. This -means, if you want to do something more than a mere dry run of this -example, you will have to patch your current kernel in order to have -|sys_\*-\*-\*_call_\*-\*-\*_table| exported. - -Blocking Processes and threads -============================== - -Sleep ------ - -What do you do when somebody asks you for something you can not do right -away? If you are a human being and you are bothered by a human being, -the only thing you can say is: "*Not right now, I’m busy. Go away_*". -But if you are a kernel module and you are bothered by a process, you -have another possibility. You can put the process to sleep until you can -service it. After all, processes are being put to sleep by the kernel -and woken up all the time (that is the way multiple processes appear to -run on the same time on a single CPU). - -This kernel module is an example of this. The file (called -`/proc/sleep`) can only be opened by a single process at a time. If the -file is already open, the kernel module calls -|wait_\*-\*-\*_event_\*-\*-\*_interruptible|. The easiest way to keep a -file open is to open it with: - -tail -f - -This function changes the status of the task (a task is the kernel data -structure which holds information about a process and the system call it -is in, if any) to |TASK_\*-\*-\*_INTERRUPTIBLE|, which means that the -task will not run until it is woken up somehow, and adds it to WaitQ, -the queue of tasks waiting to access the file. Then, the function calls -the scheduler to context switch to a different process, one which has -some use for the CPU. - -When a process is done with the file, it closes it, and -|module_\*-\*-\*_close| is called. That function wakes up all the -processes in the queue (there’s no mechanism to only wake up one of -them). It then returns and the process which just closed the file can -continue to run. In time, the scheduler decides that that process has -had enough and gives control of the CPU to another process. Eventually, -one of the processes which was in the queue will be given control of the -CPU by the scheduler. It starts at the point right after the call to -|wait_\*-\*-\*_event_\*-\*-\*_interruptible|. - -This means that the process is still in kernel mode - as far as the -process is concerned, it issued the open system call and the system call -has not returned yet. The process does not know somebody else used the -CPU for most of the time between the moment it issued the call and the -moment it returned. - -It can then proceed to set a global variable to tell all the other -processes that the file is still open and go on with its life. When the -other processes get a piece of the CPU, they’ll see that global variable -and go back to sleep. - -So we will use |tail -f| to keep the file open in the background, while -trying to access it with another process (again in the background, so -that we need not switch to a different vt). As soon as the first -background process is killed with kill %1 , the second is woken up, is -able to access the file and finally terminates. - -To make our life more interesting, |module_\*-\*-\*_close| does not have -a monopoly on waking up the processes which wait to access the file. A -signal, such as *Ctrl +c* (**SIGINT**) can also wake up a process. This -is because we used |wait_\*-\*-\*_event_\*-\*-\*_interruptible|. We -could have used |wait_\*-\*-\*_event| instead, but that would have -resulted in extremely angry users whose *Ctrl+c*’s are ignored. - -In that case, we want to return with |-EINTR| immediately. This is -important so users can, for example, kill the process before it receives -the file. - -There is one more point to remember. Some times processes don’t want to -sleep, they want either to get what they want immediately, or to be told -it cannot be done. Such processes use the |O_\*-\*-\*_NONBLOCK| flag -when opening the file. The kernel is supposed to respond by returning -with the error code |-EAGAIN| from operations which would otherwise -block, such as opening the file in this example. The program -|cat_\*-\*-\*_nonblock|, available in the `examples/other` directory, -can be used to open a file with |O_\*-\*-\*_NONBLOCK|. - - $ sudo insmod sleep.ko - $ cat_*-*-*_nonblock /proc/sleep - Last input: - $ tail -f /proc/sleep & - Last input: - Last input: - Last input: - Last input: - Last input: - Last input: - Last input: - tail: /proc/sleep: file truncated - [1] 6540 - $ cat_*-*-*_nonblock /proc/sleep - Open would block - $ kill %1 - [1]+ Terminated tail -f /proc/sleep - $ cat_*-*-*_nonblock /proc/sleep - Last input: - $ - -Completions ------------ - -Sometimes one thing should happen before another within a module having -multiple threads. Rather than using |/bin/sleep| commands, the kernel -has another way to do this which allows timeouts or interrupts to also -happen. - -Completions as code synchronization mechanism have three main parts, -initialization of struct completion synchronization object, the waiting -or barrier part through |wait_\*-\*-\*_for_\*-\*-\*_completion()|, and -the signalling side through a call to |complete()|. - -In the subsequent example, two threads are initiated: crank and -flywheel. It is imperative that the crank thread starts before the -flywheel thread. A completion state is established for each of these -threads, with a distinct completion defined for both the crank and -flywheel threads. At the exit point of each thread the respective -completion state is updated, and |wait_\*-\*-\*_for_\*-\*-\*_completion| -is used by the flywheel thread to ensure that it does not begin -prematurely. The crank thread uses the |complete_\*-\*-\*_all()| -function to update the completion, which lets the flywheel thread -continue. - -So even though |flywheel_\*-\*-\*_thread| is started first you should -notice when you load this module and run |dmesg|, that turning the crank -always happens first because the flywheel thread waits for the crank -thread to complete. - -There are other variations of the -|wait_\*-\*-\*_for_\*-\*-\*_completion| function, which include timeouts -or being interrupted, but this basic mechanism is enough for many common -situations without adding a lot of complexity. - -Avoiding Collisions and Deadlocks -================================= - -If processes running on different CPUs or in different threads try to -access the same memory, then it is possible that strange things can -happen or your system can lock up. To avoid this, various types of -mutual exclusion kernel functions are available. These indicate if a -section of code is "locked" or "unlocked" so that simultaneous attempts -to run it can not happen. - -Mutex ------ - -You can use kernel mutexes (mutual exclusions) in much the same manner -that you might deploy them in userland. This may be all that is needed -to avoid collisions in most cases. - -Spinlocks ---------- - -As the name suggests, spinlocks lock up the CPU that the code is running -on, taking 100% of its resources. Because of this you should only use -the spinlock mechanism around code which is likely to take no more than -a few milliseconds to run and so will not noticeably slow anything down -from the user’s point of view. - -The example here is `"irq safe"` in that if interrupts happen during the -lock then they will not be forgotten and will activate when the unlock -happens, using the |flags| variable to retain their state. - -Taking 100% of a CPU’s resources comes with greater responsibility. -Situations where the kernel code monopolizes a CPU are called **atomic -contexts**. Holding a spinlock is one of those situations. Sleeping in -atomic contexts may leave the system hanging, as the occupied CPU -devotes 100% of its resources doing nothing but sleeping. In some worse -cases the system may crash. Thus, sleeping in atomic contexts is -considered a bug in the kernel. They are sometimes called -“sleep-in-atomic-context” in some materials. - -Note that sleeping here is not limited to calling the sleep functions -explicitly. If subsequent function calls eventually invoke a function -that sleeps, it is also considered sleeping. Thus, it is important to -pay attention to functions being used in atomic context. There’s no -documentation recording all such functions, but code comments may help. -Sometimes you may find comments in kernel source code stating that a -function “may sleep”, “might sleep”, or more explicitly “the caller -should not hold a spinlock”. Those comments are hints that a function -may implicitly sleep and must not be called in atomic contexts. - -Read and write locks --------------------- - -Read and write locks are specialised kinds of spinlocks so that you can -exclusively read from something or write to something. Like the earlier -spinlocks example, the one below shows an "irq safe" situation in which -if other functions were triggered from irqs which might also read and -write to whatever you are concerned with then they would not disrupt the -logic. As before it is a good idea to keep anything done within the lock -as short as possible so that it does not hang up the system and cause -users to start revolting against the tyranny of your module. - -Of course, if you know for sure that there are no functions triggered by -irqs which could possibly interfere with your logic then you can use the -simpler |read_\*-\*-\*_lock(&myrwlock)| and -|read_\*-\*-\*_unlock(&myrwlock)| or the corresponding write functions. - -Atomic operations ------------------ - -If you are doing simple arithmetic: adding, subtracting or bitwise -operations, then there is another way in the multi-CPU and -multi-hyperthreaded world to stop other parts of the system from messing -with your mojo. By using atomic operations you can be confident that -your addition, subtraction or bit flip did actually happen and was not -overwritten by some other shenanigans. An example is shown below. - -Before the C11 standard adopts the built-in atomic types, the kernel -already provided a small set of atomic types by using a bunch of tricky -architecture-specific codes. Implementing the atomic types by C11 -atomics may allow the kernel to throw away the architecture-specific -codes and letting the kernel code be more friendly to the people who -understand the standard. But there are some problems, such as the memory -model of the kernel doesn’t match the model formed by the C11 atomics. -For further details, see: - -- [kernel documentation of atomic - types](https://www.kernel.org/doc/Documentation/atomic_*-*-*_t.txt) - -- [Time to move to C11 atomics?](https://lwn.net/Articles/691128/) - -- [Atomic usage patterns in the - kernel](https://lwn.net/Articles/698315/) - -Replacing Print Macros -====================== - -Replacement ------------ - -In Section -1.7, -it was noted that the X Window System and kernel module programming are -not conducive to integration. This remains valid during the development -of kernel modules. However, in practical scenarios, the necessity -emerges to relay messages to the tty (teletype) originating the module -load command. - -The term “tty” originates from *teletype*, which initially referred to a -combined keyboard-printer for Unix system communication. Today, it -signifies a text stream abstraction employed by Unix programs, -encompassing physical terminals, xterms in X displays, and network -connections like SSH. - -To achieve this, the “current” pointer is leveraged to access the active -task’s tty structure. Within this structure lies a pointer to a string -write function, facilitating the string’s transmission to the tty. - -Flashing keyboard LEDs ----------------------- - -In certain conditions, you may desire a simpler and more direct way to -communicate to the external world. Flashing keyboard LEDs can be such a -solution: It is an immediate way to attract attention or to display a -status condition. Keyboard LEDs are present on every hardware, they are -always visible, they do not need any setup, and their use is rather -simple and non-intrusive, compared to writing to a tty or a file. - -From v4.14 to v4.15, the timer API made a series of changes to improve -memory safety. A buffer overflow in the area of a |timer_\*-\*-\*_list| -structure may be able to overwrite the |function| and |data| fields, -providing the attacker with a way to use return-oriented programming -(ROP) to call arbitrary functions within the kernel. Also, the function -prototype of the callback, containing a |unsigned long| argument, will -prevent work from any type checking. Furthermore, the function prototype -with |unsigned long| argument may be an obstacle to the forward-edge -protection of *control-flow integrity*. Thus, it is better to use a -unique prototype to separate from the cluster that takes an |unsigned -long| argument. The timer callback should be passed a pointer to the -|timer_\*-\*-\*_list| structure rather than an |unsigned long| argument. -Then, it wraps all the information the callback needs, including the -|timer_\*-\*-\*_list| structure, into a larger structure, and it can use -the |container_\*-\*-\*_of| macro instead of the |unsigned long| value. -For more information see: [Improving the kernel timers -API](https://lwn.net/Articles/735887/). - -Before Linux v4.14, |setup_\*-\*-\*_timer| was used to initialize the -timer and the |timer_\*-\*-\*_list| structure looked like: - -struct timer_\*-\*-\*_list unsigned long expires; void -(\*function)(unsigned long); unsigned long data; u32 flags; /\* ... \*/ -; - -void setup_\*-\*-\*_timer(struct timer_\*-\*-\*_list \*timer, void -(\*callback)(unsigned long), unsigned long data); - -Since Linux v4.14, |timer_\*-\*-\*_setup| is adopted and the kernel step -by step converting to |timer_\*-\*-\*_setup| from -|setup_\*-\*-\*_timer|. One of the reasons why API was changed is it -need to coexist with the old version interface. Moreover, the -|timer_\*-\*-\*_setup| was implemented by |setup_\*-\*-\*_timer| at -first. - -void timer_\*-\*-\*_setup(struct timer_\*-\*-\*_list \*timer, void -(\*callback)(struct timer_\*-\*-\*_list \*), unsigned int flags); - -The |setup_\*-\*-\*_timer| was then removed since v4.15. As a result, -the |timer_\*-\*-\*_list| structure had changed to the following. - -struct timer_\*-\*-\*_list unsigned long expires; void -(\*function)(struct timer_\*-\*-\*_list \*); u32 flags; /\* ... \*/ ; - -The following source code illustrates a minimal kernel module which, -when loaded, starts blinking the keyboard LEDs until it is unloaded. - -If none of the examples in this chapter fit your debugging needs, there -might yet be some other tricks to try. Ever wondered what -|CONFIG_\*-\*-\*_LL_\*-\*-\*_DEBUG| in |make menuconfig| is good for? If -you activate that you get low level access to the serial port. While -this might not sound very powerful by itself, you can patch -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/kernel/printk.c) -or any other essential syscall to print ASCII characters, thus making it -possible to trace virtually everything what your code does over a serial -line. If you find yourself porting the kernel to some new and former -unsupported architecture, this is usually amongst the first things that -should be implemented. Logging over a netconsole might also be worth a -try. - -While you have seen lots of stuff that can be used to aid debugging -here, there are some things to be aware of. Debugging is almost always -intrusive. Adding debug code can change the situation enough to make the -bug seem to disappear. Thus, you should keep debug code to a minimum and -make sure it does not show up in production code. - -Scheduling Tasks -================ - -There are two main ways of running tasks: tasklets and work queues. -Tasklets are a quick and easy way of scheduling a single function to be -run. For example, when triggered from an interrupt, whereas work queues -are more complicated but also better suited to running multiple things -in a sequence. - -It is possible that in future tasklets may be replaced by *threaded -irqs*. However, discussion about that has been ongoing since 2007 -([Eliminating tasklets](https://lwn.net/Articles/239633)), so do not -hold your breath. See the section -15.1 -if you wish to avoid the tasklet debate. - -Tasklets --------- - -Here is an example tasklet module. The |tasklet_\*-\*-\*_fn| function -runs for a few seconds. In the meantime, execution of the -|example_\*-\*-\*_tasklet_\*-\*-\*_init| function may continue to the -exit point, depending on whether it is interrupted by **softirq**. - -So with this example loaded |dmesg| should show: - - tasklet example init - Example tasklet starts - Example tasklet init continues... - Example tasklet ends - -Although tasklet is easy to use, it comes with several drawbacks, and -developers are discussing about getting rid of tasklet in linux kernel. -The tasklet callback runs in atomic context, inside a software -interrupt, meaning that it cannot sleep or access user-space data, so -not all work can be done in a tasklet handler. Also, the kernel only -allows one instance of any given tasklet to be running at any given -time; multiple different tasklet callbacks can run in parallel. - -In recent kernels, tasklets can be replaced by workqueues, timers, or -threaded interrupts.[1] While the removal of tasklets remains a -longer-term goal, the current kernel contains more than a hundred uses -of tasklets. Now developers are proceeding with the API changes and the -macro |DECLARE_\*-\*-\*_TASKLET_\*-\*-\*_OLD| exists for compatibility. -For further information, see . - -Work queues ------------ - -To add a task to the scheduler we can use a workqueue. The kernel then -uses the Completely Fair Scheduler (CFS) to execute work within the -queue. - -Interrupt Handlers -================== - -Interrupt Handlers ------------------- - -Except for the last chapter, everything we did in the kernel so far we -have done as a response to a process asking for it, either by dealing -with a special file, sending an |ioctl()|, or issuing a system call. But -the job of the kernel is not just to respond to process requests. -Another job, which is every bit as important, is to speak to the -hardware connected to the machine. - -There are two types of interaction between the CPU and the rest of the -computer’s hardware. The first type is when the CPU gives orders to the -hardware, the other is when the hardware needs to tell the CPU -something. The second, called interrupts, is much harder to implement -because it has to be dealt with when convenient for the hardware, not -the CPU. Hardware devices typically have a very small amount of RAM, and -if you do not read their information when available, it is lost. - -Under Linux, hardware interrupts are called IRQ’s (Interrupt ReQuests). -There are two types of IRQ’s, short and long. A short IRQ is one which -is expected to take a very short period of time, during which the rest -of the machine will be blocked and no other interrupts will be handled. -A long IRQ is one which can take longer, and during which other -interrupts may occur (but not interrupts from the same device). If at -all possible, it is better to declare an interrupt handler to be long. - -When the CPU receives an interrupt, it stops whatever it is doing -(unless it is processing a more important interrupt, in which case it -will deal with this one only when the more important one is done), saves -certain parameters on the stack and calls the interrupt handler. This -means that certain things are not allowed in the interrupt handler -itself, because the system is in an unknown state. Linux kernel solves -the problem by splitting interrupt handling into two parts. The first -part executes right away and masks the interrupt line. Hardware -interrupts must be handled quickly, and that is why we need the second -part to handle the heavy work deferred from an interrupt handler. -Historically, BH (Linux naming for *Bottom Halves*) statistically -book-keeps the deferred functions. **Softirq** and its higher level -abstraction, **Tasklet**, replace BH since Linux 2.3. - -The way to implement this is to call |request_\*-\*-\*_irq()| to get -your interrupt handler called when the relevant IRQ is received. - -In practice IRQ handling can be a bit more complex. Hardware is often -designed in a way that chains two interrupt controllers, so that all the -IRQs from interrupt controller B are cascaded to a certain IRQ from -interrupt controller A. Of course, that requires that the kernel finds -out which IRQ it really was afterwards and that adds overhead. Other -architectures offer some special, very low overhead, so called "fast -IRQ" or FIQs. To take advantage of them requires handlers to be written -in assembly language, so they do not really fit into the kernel. They -can be made to work similar to the others, but after that procedure, -they are no longer any faster than "common" IRQs. SMP enabled kernels -running on systems with more than one processor need to solve another -truckload of problems. It is not enough to know if a certain IRQs has -happened, it’s also important to know what CPU(s) it was for. People -still interested in more details, might want to refer to "APIC" now. - -This function receives the IRQ number, the name of the function, flags, -a name for `/proc/interrupts` and a parameter to be passed to the -interrupt handler. Usually there is a certain number of IRQs available. -How many IRQs there are is hardware-dependent. - -The flags can be used for specify behaviors of the IRQ. For example, use -|IRQF_\*-\*-\*_SHARED| to indicate you are willing to share the IRQ with -other interrupt handlers (usually because a number of hardware devices -sit on the same IRQ); use the |IRQF_\*-\*-\*_ONESHOT| to indicate that -the IRQ is not reenabled after the handler finished. It should be noted -that in some materials, you may encouter another set of IRQ flags named -with the |SA| prefix. For example, the |SA_\*-\*-\*_SHIRQ| and the -|SA_\*-\*-\*_INTERRUPT|. Those are the the IRQ flags in the older -kernels. They have been removed completely. Today only the |IRQF| flags -are in use. This function will only succeed if there is not already a -handler on this IRQ, or if you are both willing to share. - -Detecting button presses ------------------------- - -Many popular single board computers, such as Raspberry Pi or -Beagleboards, have a bunch of GPIO pins. Attaching buttons to those and -then having a button press do something is a classic case in which you -might need to use interrupts, so that instead of having the CPU waste -time and battery power polling for a change in input state, it is better -for the input to trigger the CPU to then run a particular handling -function. - -Here is an example where buttons are connected to GPIO numbers 17 and 18 -and an LED is connected to GPIO 4. You can change those numbers to -whatever is appropriate for your board. - -Bottom Half ------------ - -Suppose you want to do a bunch of stuff inside of an interrupt routine. -A common way to do that without rendering the interrupt unavailable for -a significant duration is to combine it with a tasklet. This pushes the -bulk of the work off into the scheduler. - -The example below modifies the previous example to also run an -additional task when an interrupt is triggered. - -Threaded IRQ ------------- - -Threaded IRQ is a mechanism to organize both top-half and bottom-half of -an IRQ at once. A threaded IRQ splits the one handler in -|request_\*-\*-\*_irq()| into two: one for the top-half, the other for -the bottom-half. The |request_\*-\*-\*_threaded_\*-\*-\*_irq()| is the -function for using threaded IRQs. Two handlers are registered at once in -the |request_\*-\*-\*_threaded_\*-\*-\*_irq()|. - -Those two handlers run in different context. The top-half handler runs -in interrupt context. It’s the equivalence of the handler passed to the -|request_\*-\*-\*_irq()|. The bottom-half handler on the other hand runs -in its own thread. This thread is created on registration of a threaded -IRQ. Its sole purpose is to run this bottom-half handler. This is where -a threaded IRQ is “threaded”. If |IRQ_\*-\*-\*_WAKE_\*-\*-\*_THREAD| is -returned by the top-half handler, that bottom-half serving thread will -wake up. The thread then runs the bottom-half handler. - -Here is an example of how to do the same thing as before, with top and -bottom halves, but using threads. - -A threaded IRQ is registered using -|request_\*-\*-\*_threaded_\*-\*-\*_irq()|. This function only takes one -additional parameter than the |request_\*-\*-\*_irq()| – the bottom-half -handling function that runs in its own thread. In this example it is the -|button_\*-\*-\*_bottom_\*-\*-\*_half()|. Usage of other parameters are -the same as |request_\*-\*-\*_irq()|. - -Presence of both handlers is not mandatory. If either of them is not -needed, pass the |NULL| instead. A |NULL| top-half handler implies that -no action is taken except to wake up the bottom-half serving thread, -which runs the bottom-half handler. Similarly, a |NULL| bottom-half -handler effectively acts as if |request_\*-\*-\*_irq()| were used. In -fact, this is how |request_\*-\*-\*_irq()| is implemented. - -Note that passing |NULL| to both handlers is considered an error and -will make registration fail. - -Virtual Input Device Driver -=========================== - -The input device driver is a module that provides a way to communicate -with the interaction device via the event. For example, the keyboard can -send the press or release event to tell the kernel what we want to do. -The input device driver will allocate a new input structure with -|input_\*-\*-\*_allocate_\*-\*-\*_device()| and sets up input bitfields, -device id, version, etc. After that, registers it by calling -|input_\*-\*-\*_register_\*-\*-\*_device()|. - -Here is an example, vinput, It is an API to allow easy development of -virtual input drivers. The drivers needs to export a -|vinput_\*-\*-\*_device()| that contains the virtual device name and -|vinput_\*-\*-\*_ops| structure that describes: - -- the init function: |init()| - -- the input event injection function: |send()| - -- the readback function: |read()| - -Then using |vinput_\*-\*-\*_register_\*-\*-\*_device()| and -|vinput_\*-\*-\*_unregister_\*-\*-\*_device()| will add a new device to -the list of support virtual input devices. - -int init(struct vinput \*); - -This function is passed a |struct vinput| already initialized with an -allocated |struct input_\*-\*-\*_dev|. The |init()| function is -responsible for initializing the capabilities of the input device and -register it. - -int send(struct vinput \*, char \*, int); - -This function will receive a user string to interpret and inject the -event using the |input_\*-\*-\*_report_\*-\*-\*_XXXX| or -|input_\*-\*-\*_event| call. The string is already copied from user. - -int read(struct vinput \*, char \*, int); - -This function is used for debugging and should fill the buffer parameter -with the last event sent in the virtual input device format. The buffer -will then be copied to user. - -vinput devices are created and destroyed using sysfs. And, event -injection is done through a `/dev` node. The device name will be used by -the userland to export a new virtual input device. - -The |class_\*-\*-\*_attribute| structure is similar to other attribute -types we talked about in section -8: - -struct class_\*-\*-\*_attribute struct attribute attr; ssize_\*-\*-\*_t -(\*show)(struct class \*class, struct class_\*-\*-\*_attribute \*attr, -char \*buf); ssize_\*-\*-\*_t (\*store)(struct class \*class, struct -class_\*-\*-\*_attribute \*attr, const char \*buf, size_\*-\*-\*_t -count); ; - -In `vinput.c`, the macro -|CLASS_\*-\*-\*_ATTR_\*-\*-\*_WO(export/unexport)| defined in -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/device.h) -(in this case, `device.h` is included in -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/input.h)) -will generate the |class_\*-\*-\*_attribute| structures which are named -`class_*-*-*_attr_*-*-*_export/unexport`. Then, put them into -|vinput_\*-\*-\*_class_\*-\*-\*_attrs| array and the macro -|ATTRIBUTE_\*-\*-\*_GROUPS(vinput_\*-\*-\*_class)| will generate the -|struct attribute_\*-\*-\*_group vinput_\*-\*-\*_class_\*-\*-\*_group| -that should be assigned in |vinput_\*-\*-\*_class|. Finally, call -|class_\*-\*-\*_register(&vinput_\*-\*-\*_class)| to create attributes -in sysfs. - -To create a `vinputX` sysfs entry and `/dev` node. - -echo "vkbd" | sudo tee /sys/class/vinput/export - -To unexport the device, just echo its id in unexport: - -echo "0" | sudo tee /sys/class/vinput/unexport - -Here the virtual keyboard is one of example to use vinput. It supports -all |KEY_\*-\*-\*_MAX| keycodes. The injection format is the -|KEY_\*-\*-\*_CODE| such as defined in -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/input.h). -A positive value means |KEY_\*-\*-\*_PRESS| while a negative value is a -|KEY_\*-\*-\*_RELEASE|. The keyboard supports repetition when the key -stays pressed for too long. The following demonstrates how simulation -work. - -Simulate a key press on "g" (|KEY_\*-\*-\*_G| = 34): - -echo "+34" | sudo tee /dev/vinput0 - -Simulate a key release on "g" (|KEY_\*-\*-\*_G| = 34): - -echo "-34" | sudo tee /dev/vinput0 - -Standardizing the interfaces: The Device Model -============================================== - -Up to this point we have seen all kinds of modules doing all kinds of -things, but there was no consistency in their interfaces with the rest -of the kernel. To impose some consistency such that there is at minimum -a standardized way to start, suspend and resume a device model was -added. An example is shown below, and you can use this as a template to -add your own suspend, resume or other interface functions. - -Optimizations -============= - -Likely and Unlikely conditions ------------------------------- - -Sometimes you might want your code to run as quickly as possible, -especially if it is handling an interrupt or doing something which might -cause noticeable latency. If your code contains boolean conditions and -if you know that the conditions are almost always likely to evaluate as -either |true| or |false|, then you can allow the compiler to optimize -for this using the |likely| and |unlikely| macros. For example, when -allocating memory you are almost always expecting this to succeed. - -bvl = bvec_\*-\*-\*_alloc(gfp_\*-\*-\*_mask, nr_\*-\*-\*_iovecs, &idx); -if (unlikely(_bvl)) mempool_\*-\*-\*_free(bio, bio_\*-\*-\*_pool); bio = -NULL; goto out; - -When the |unlikely| macro is used, the compiler alters its machine -instruction output, so that it continues along the false branch and only -jumps if the condition is true. That avoids flushing the processor -pipeline. The opposite happens if you use the |likely| macro. - -Static keys ------------ - -Static keys allow us to enable or disable kernel code paths based on the -runtime state of key. Its APIs have been available since 2010 (most -architectures are already supported), use self-modifying code to -eliminate the overhead of cache and branch prediction. The most typical -use case of static keys is for performance-sensitive kernel code, such -as tracepoints, context switching, networking, etc. These hot paths of -the kernel often contain branches and can be optimized easily using this -technique. Before we can use static keys in the kernel, we need to make -sure that gcc supports |asm goto| inline assembly, and the following -kernel configurations are set: - -CONFIG_\*-\*-\*_JUMP_\*-\*-\*_LABEL=y -CONFIG_\*-\*-\*_HAVE_\*-\*-\*_ARCH_\*-\*-\*_JUMP_\*-\*-\*_LABEL=y -CONFIG_\*-\*-\*_HAVE_\*-\*-\*_ARCH_\*-\*-\*_JUMP_\*-\*-\*_LABEL_\*-\*-\*_RELATIVE=y - -To declare a static key, we need to define a global variable using the -|DEFINE_\*-\*-\*_STATIC_\*-\*-\*_KEY_\*-\*-\*_FALSE| or -|DEFINE_\*-\*-\*_STATIC_\*-\*-\*_KEY_\*-\*-\*_TRUE| macro defined in -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/jump\_*-*-*_label.h). -This macro initializes the key with the given initial value, which is -either false or true, respectively. For example, to declare a static key -with an initial value of false, we can use the following code: - -DEFINE_\*-\*-\*_STATIC_\*-\*-\*_KEY_\*-\*-\*_FALSE(fkey); - -Once the static key has been declared, we need to add branching code to -the module that uses the static key. For example, the code includes a -fastpath, where a no-op instruction will be generated at compile time as -the key is initialized to false and the branch is unlikely to be taken. - -pr_\*-\*-\*_info("fastpath 1"); if -(static_\*-\*-\*_branch_\*-\*-\*_unlikely(&fkey)) pr_\*-\*-\*_alert("do -unlikely thing"); pr_\*-\*-\*_info("fastpath 2"); - -If the key is enabled at runtime by calling -|static_\*-\*-\*_branch_\*-\*-\*_enable(&fkey)|, the fastpath will be -patched with an unconditional jump instruction to the slowpath code -|pr_\*-\*-\*_alert|, so the branch will always be taken until the key is -disabled again. - -The following kernel module derived from `chardev.c`, demonstrates how -the static key works. - -To check the state of the static key, we can use the -`/dev/key_*-*-*_state` interface. - -cat /dev/key_\*-\*-\*_state - -This will display the current state of the key, which is disabled by -default. - -To change the state of the static key, we can perform a write operation -on the file: - -echo enable > /dev/key_\*-\*-\*_state - -This will enable the static key, causing the code path to switch from -the fastpath to the slowpath. - -In some cases, the key is enabled or disabled at initialization and -never changed, we can declare a static key as read-only, which means -that it can only be toggled in the module init function. To declare a -read-only static key, we can use the -|DEFINE_\*-\*-\*_STATIC_\*-\*-\*_KEY_\*-\*-\*_FALSE_\*-\*-\*_RO| or -|DEFINE_\*-\*-\*_STATIC_\*-\*-\*_KEY_\*-\*-\*_TRUE_\*-\*-\*_RO| macro -instead. Attempts to change the key at runtime will result in a page -fault. For more information, see [Static -keys](https://www.kernel.org/doc/Documentation/static-keys.txt) - -Common Pitfalls -=============== - -Using standard libraries ------------------------- - -You can not do that. In a kernel module, you can only use kernel -functions which are the functions you can see in `/proc/kallsyms`. - -Disabling interrupts --------------------- - -You might need to do this for a short time and that is OK, but if you do -not enable them afterwards, your system will be stuck and you will have -to power it off. - -Where To Go From Here? -====================== - -For those deeply interested in kernel programming, -[kernelnewbies.org](https://kernelnewbies.org) and the -[](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation) -subdirectory within the kernel source code are highly recommended. -Although the latter may not always be straightforward, it serves as a -valuable initial step for further exploration. Echoing Linus Torvalds’ -perspective, the most effective method to understand the kernel is -through personal examination of the source code. - -Contributions to this guide are welcome, especially if there are any -significant inaccuracies identified. To contribute or report an issue, -please initiate an issue at . Pull -requests are greatly appreciated. - -Happy hacking_ - -[1] The goal of threaded interrupts is to push more of the work to -separate threads, so that the minimum needed for acknowledging an -interrupt is reduced, and therefore the time spent handling the -interrupt (where it can’t handle any other interrupts at the same time) -is reduced. See . diff --git a/scripts/Contributors b/scripts/Contributors deleted file mode 100644 index 4a81aaa..0000000 --- a/scripts/Contributors +++ /dev/null @@ -1,59 +0,0 @@ -Amit Dhingra, -Andy Shevchenko, -Arush Sharma,<46960231+arushsharma24@users.noreply.github.com> -Benno Bielmeier,<32938211+bbenno@users.noreply.github.com> -Bob Lee, -Brad Baker, -Che-Chia Chang, -Cheng-Shian Yeh, -Chih-En Lin,,<0086d026@email.ntou.edu.tw>,<66012716+linD026@users.noreply.github.com> -Chih-Hsuan Yang, -Chih-Yu Chen,<34228283+chihyu1206@users.noreply.github.com> -Ching-Hua (Vivian) Lin, -Chin Yik Ming, -cvvletter, -Cyril Brulebois, -Daniele Paolo Scarpazza,<> -David Porter,<> -demonsome, -Dimo Velev,<> -Ekang Monyet, -Ethan Chan, -Francois Audeon,<> -Gilad Reti, -heartofrain, -Horst Schirmeier,<> -Hsin-Hsiang Peng, -Ignacio Martin,<> -I-Hsin Cheng, -Iûnn Kiàn-îng, -Jian-Xing Wu, -Johan Calle,<43998967+jcallemc@users.noreply.github.com> -keytouch, -Kohei Otsuka,<13173186+rjhcnf@users.noreply.github.com> -Kuan-Wei Chiu, -manbing, -Marconi Jiang, -mengxinayan,<31788564+mengxinayan@users.noreply.github.com> -Meng-Zong Tsai,,<58484289+fennecJ@users.noreply.github.com> -Peter Lin,,, -Roman Lakeev,<> -Sam Erickson, -Shao-Tse Hung, -Shih-Sheng Yang, -Stacy Prowell, -Steven Lung,<1030steven@gmail.com> -Tristan Lelong, -Tse-Wei Lin,<20110901eric@outlook.com> -Tucker Polomik, -Tyler Fanelli, -VxTeemo, -Wei-Hsin Yeh,,<90430653+weihsinyeh@users.noreply.github.com> -Wei-Lun Tsai, -Xatierlike Lee, -Yen-Yu Chen,,<69316865+YLowy@users.noreply.github.com> -Yin-Chiuan Chen, -Yi-Wei Lin, -Yo-Jung Lin,<0xff07@gmail.com>, -Yu-Hsiang Tseng, -YYGO, diff --git a/scripts/Exclude b/scripts/Exclude deleted file mode 100644 index 8514591..0000000 --- a/scripts/Exclude +++ /dev/null @@ -1 +0,0 @@ -Jim Huang, One of main author diff --git a/scripts/Include b/scripts/Include deleted file mode 100644 index b54c0ce..0000000 --- a/scripts/Include +++ /dev/null @@ -1,8 +0,0 @@ -Daniele Paolo Scarpazza,<> -David Porter,<> -Dimo Velev,<> -Francois Audeon,<> -Horst Schirmeier,<> -Ignacio Martin,<> -Roman Lakeev,<> -Tristan Lelong, diff --git a/scripts/list-contributors.sh b/scripts/list-contributors.sh deleted file mode 100755 index 6bbe963..0000000 --- a/scripts/list-contributors.sh +++ /dev/null @@ -1,60 +0,0 @@ -#!/usr/bin/env bash -FORMAT="%aN,<%aE>" #Set git output format in "Name," //Capital in aN and aE means replace str based on .mailmap -TARGET=(examples lkmpg.tex) #Target files we want to trace -DIR=`git rev-parse --show-toplevel` #Get root dir of the repo -TARGET=("${TARGET[@]/#/$DIR/}") #Concat $DIR BEFORE ALL elements in array TARGET - -#The str in each line should be Username, -function gen-raw-list() -{ - git log --pretty="$FORMAT" ${TARGET[@]} | sort -u -} - -function parse-list() -{ - > Contributors # Clear contributors' list (Overwrite with null) - while read -r line; do - User=`echo "$line" | awk -F "," '{print $1}'` - if [[ `grep -w "$User" Exclude` ]]; then - echo "[skip] $User" - continue; - fi - echo "[Add] $User" - MainMail=`echo "$line" | awk -F "[<*>]" '{print $2}'` - Emails=(`cat $DIR/.mailmap | grep -w "$User" | awk -F "[<*>]" '{print $4}' | sort -u`) - for Email in ${Emails[@]}; do - if [[ "$Email" != "$MainMail" ]]; then - line="$line,<$Email>"; - fi - done - echo "$line" >> Contributors - done <<< $(gen-raw-list) - cat Include >> Contributors -} - -function sort-list() -{ - if [[ `git diff Contributors` ]]; then - sort -f -o Contributors{,} - git add $DIR/scripts/Contributors - fi -} - -#For all lines before endline, print "name, % " -#For endline print "name. % " -function gen-tex-file() -{ - cat Contributors | awk -F "," \ - ' BEGIN{k=0}{name[k]=$1;email[k++]=$2} - END{ - for(i=0;i $DIR/contrib.tex \ No newline at end of file diff --git a/示例/0-hello/Makefile b/示例/0-hello/Makefile new file mode 100644 index 0000000..09502cd --- /dev/null +++ b/示例/0-hello/Makefile @@ -0,0 +1,17 @@ +obj-m += hello-1.o +obj-m += hello-2.o +obj-m += hello-3.o +obj-m += hello-4.o +obj-m += hello-5.o +obj-m += startstop.o +startstop-objs := start.o stop.o + + +PWD := $(CURDIR) + +all: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules + +clean: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean + diff --git a/示例/0-hello/hello-1.c b/示例/0-hello/hello-1.c new file mode 100644 index 0000000..8ea543e --- /dev/null +++ b/示例/0-hello/hello-1.c @@ -0,0 +1,21 @@ +/* + * hello-1.c - 最简单的内核模块 + */ +#include /* 内核模块必要的头 */ +#include /* 引入 pr_info() */ + +int init_module(void) +{ + pr_info("你好,世界 1(报错返回).\n"); + + /* 非0返回意味着init_module失败; 无法加载模块 */ + return 1; +} + +void cleanup_module(void) +{ + pr_info("再见,世界 1.\n"); +} + +MODULE_LICENSE("GPL"); + diff --git a/示例/0-hello/hello-2.c b/示例/0-hello/hello-2.c new file mode 100644 index 0000000..92435dc --- /dev/null +++ b/示例/0-hello/hello-2.c @@ -0,0 +1,24 @@ +/* + * hello-2.c - 演示module_init()和module_exit()宏 + * 这比使用init_module()和cleanup_module()更受欢迎 + */ +#include /* 初始化需要的宏 */ +#include /* 内核模块必要的头 */ +#include /* 引入 pr_info() */ + +static int __init hello_2_init(void) +{ + pr_info("你好 2\n"); + return 0; +} + +static void __exit hello_2_exit(void) +{ + pr_info("再见 2\n"); +} + +module_init(hello_2_init); +module_exit(hello_2_exit); + +MODULE_LICENSE("GPL"); + diff --git a/示例/0-hello/hello-3.c b/示例/0-hello/hello-3.c new file mode 100644 index 0000000..f503c85 --- /dev/null +++ b/示例/0-hello/hello-3.c @@ -0,0 +1,25 @@ +/* + * hello-3.c - __init, __initdata 和 __exit 宏的使用说明 + */ +#include /* 初始化需要的宏 */ +#include /* 内核模块必要的头 */ +#include /* 引入 pr_info() */ + +static int hello3_data __initdata = 3; + +static int __init hello_3_init(void) +{ + pr_info("Hello, world %d\n", hello3_data); + return 0; +} + +static void __exit hello_3_exit(void) +{ + pr_info("Goodbye, world 3\n"); +} + +module_init(hello_3_init); +module_exit(hello_3_exit); + +MODULE_LICENSE("GPL"); + diff --git a/示例/0-hello/hello-4.c b/示例/0-hello/hello-4.c new file mode 100644 index 0000000..3141001 --- /dev/null +++ b/示例/0-hello/hello-4.c @@ -0,0 +1,25 @@ +/* + * hello-4.c - 演示模块文档 + */ +#include /* 初始化需要的宏 */ +#include /* 内核模块必要的头 */ +#include /* 引入 pr_info() */ + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("寻觅"); +MODULE_DESCRIPTION("一个练习驱动"); + +static int __init init_hello_4(void) +{ + pr_info("Hello, world 4\n"); + return 0; +} + +static void __exit cleanup_hello_4(void) +{ + pr_info("Goodbye, world 4\n"); +} + +module_init(init_hello_4); +module_exit(cleanup_hello_4); + diff --git a/示例/0-hello/hello-5.c b/示例/0-hello/hello-5.c new file mode 100644 index 0000000..9eedfc0 --- /dev/null +++ b/示例/0-hello/hello-5.c @@ -0,0 +1,67 @@ +/* + * hello-5.c - 演示传递给模块的命令行参数 + */ +#include +#include /* 引入 ARRAY_SIZE() */ +#include +#include +#include +#include + +MODULE_LICENSE("GPL"); + +static short int myshort = 1; +static int myint = 420; +static long int mylong = 9999; +static char *mystring = "寻觅"; +static int myintarray[2] = { 420, 420 }; +static int arr_argc = 0; + +/* module_param(foo, int, 0000) + * foo: 传入参数的名称 + * int: 参数的数据类型 + * 0000: 权限位, 用于在稍后阶段公开sysfs中的参数(如果非零) + */ +module_param(myshort, short, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP); +MODULE_PARM_DESC(myshort, "一个短整数"); +module_param(myint, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); +MODULE_PARM_DESC(myint, "一个整数"); +module_param(mylong, long, S_IRUSR); +MODULE_PARM_DESC(mylong, "一个长整数"); +module_param(mystring, charp, 0000); +MODULE_PARM_DESC(mystring, "一个字符"); + +/* module_param_array(name, type, num, perm); + * name: 数组的名称 + * type: 数组元素的类型 + * num: 指向变量的指针, 该变量将在模块加载时存储用户初始化的数组元素数量 + * perm: 权限位 + */ +module_param_array(myintarray, int, &arr_argc, 0000); +MODULE_PARM_DESC(myintarray, "一组整数数组"); + +static int __init hello_5_init(void) +{ + int i; + + pr_info("你好 5\n=============\n"); + pr_info("myshort是一个短整数: %hd\n", myshort); + pr_info("myint是一个整数: %d\n", myint); + pr_info("mylong是一个长整数: %ld\n", mylong); + pr_info("mystring是一个字符: %s\n", mystring); + + for (i = 0; i < ARRAY_SIZE(myintarray); i++) + pr_info("myintarray[%d] = %d\n", i, myintarray[i]); + + pr_info("从 myintarray 中获得 %d 个参数\n", arr_argc); + return 0; +} + +static void __exit hello_5_exit(void) +{ + pr_info("再见 5\n"); +} + +module_init(hello_5_init); +module_exit(hello_5_exit); + diff --git a/示例/0-hello/hello.c b/示例/0-hello/hello.c new file mode 100644 index 0000000..cffc835 --- /dev/null +++ b/示例/0-hello/hello.c @@ -0,0 +1,7 @@ +#include + +int main(void) +{ + printf("你好"); + return 0; +} diff --git a/示例/0-hello/start.c b/示例/0-hello/start.c new file mode 100644 index 0000000..7fbdb5f --- /dev/null +++ b/示例/0-hello/start.c @@ -0,0 +1,15 @@ +/* + * start.c - 跨文件模块-初始化 + */ + +#include /* 进行内核工作时引入的头 */ +#include /* 内核模块必要的头 */ + +int init_module(void) +{ + pr_info("你好, 内核初始化模块启动\n"); + return 0; +} + +MODULE_LICENSE("GPL"); + diff --git a/示例/0-hello/stop.c b/示例/0-hello/stop.c new file mode 100644 index 0000000..30733ee --- /dev/null +++ b/示例/0-hello/stop.c @@ -0,0 +1,14 @@ +/* + * stop.c - 跨文件模块-结束 + */ + +#include /* 进行内核工作时引入的头 */ +#include /* 内核模块必要的头 */ + +void cleanup_module(void) +{ + pr_info("一个很短的内核结束模块\n"); +} + +MODULE_LICENSE("GPL"); + diff --git a/示例/1-chardev/Makefile b/示例/1-chardev/Makefile new file mode 100644 index 0000000..86e6938 --- /dev/null +++ b/示例/1-chardev/Makefile @@ -0,0 +1,11 @@ +obj-m += chardev.o + + +PWD := $(CURDIR) + +all: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules + +clean: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean + diff --git a/示例/1-chardev/chardev.c b/示例/1-chardev/chardev.c new file mode 100644 index 0000000..4a95d05 --- /dev/null +++ b/示例/1-chardev/chardev.c @@ -0,0 +1,161 @@ +/* + * chardev.c: 创建一个只读 char 设备，显示从 dev 文件读取的次数 + */ + +#include +#include +#include +#include +#include +#include +#include /* 引入 sprintf() */ +#include +#include +#include +#include /* 引入 get_user 和 put_user */ +#include + +#include + +/* 原型(Prototypes) - 这通常会放在一个 .h 文件中 */ +static int device_open(struct inode *, struct file *); +static int device_release(struct inode *, struct file *); +static ssize_t device_read(struct file *, char __user *, size_t, loff_t *); +static ssize_t device_write(struct file *, const char __user *, size_t, + loff_t *); + +#define SUCCESS 0 +#define DEVICE_NAME "chardev" /* 在/proc/devices中显示的Dev名称 */ +#define BUF_LEN 80 /* 来自驱动消息的最大长度 */ + +/* 全局变量声明为静态的, 文件中的全局变量也是如此 */ + +static int major; /* 分配给设备驱动程序的主编号 */ + +enum { + CDEV_NOT_USED = 0, + CDEV_EXCLUSIVE_OPEN = 1, +}; + +/* 设备是否打开？用于防止多次访问设备 */ +static atomic_t already_open = ATOMIC_INIT(CDEV_NOT_USED); + +static char msg[BUF_LEN + 1]; /* 当被请求时，设备将给出的信息 */ + +static struct class *cls; + +static struct file_operations chardev_fops = { + .read = device_read, + .write = device_write, + .open = device_open, + .release = device_release, +}; + +static int __init chardev_init(void) +{ + major = register_chrdev(0, DEVICE_NAME, &chardev_fops); + + if (major < 0) { + pr_alert("注册字符设备失败 %d\n", major); + return major; + } + + pr_info("分配的主编号 %d.\n", major); + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 0) + cls = class_create(DEVICE_NAME); +#else + cls = class_create(THIS_MODULE, DEVICE_NAME); +#endif + device_create(cls, NULL, MKDEV(major, 0), NULL, DEVICE_NAME); + + pr_info("设备创建于 /dev/%s\n", DEVICE_NAME); + + return SUCCESS; +} + +static void __exit chardev_exit(void) +{ + device_destroy(cls, MKDEV(major, 0)); + class_destroy(cls); + + /* 注销设备 */ + unregister_chrdev(major, DEVICE_NAME); +} + +/* 方法 */ + +/* 当进程尝试打开设备文件时调用，如 + * "sudo cat /dev/chardev" + */ +static int device_open(struct inode *inode, struct file *file) +{ + static int counter = 0; + + if (atomic_cmpxchg(&already_open, CDEV_NOT_USED, CDEV_EXCLUSIVE_OPEN)) + return -EBUSY; + + sprintf(msg, "我已经跟你说了 %d 次 Hello world!\n", counter++); + try_module_get(THIS_MODULE); + + return SUCCESS; +} + +/* 当进程关闭设备文件时调用 */ +static int device_release(struct inode *inode, struct file *file) +{ + /* 准备好迎接下一个触发 */ + atomic_set(&already_open, CDEV_NOT_USED); + + /* 减少使用次数，否则一旦打开文件，就永远无法删除模块 */ + module_put(THIS_MODULE); + + return SUCCESS; +} + +/* 当一个已打开 dev 文件的进程试图读取该文件时调用 */ +static ssize_t device_read(struct file *filp, /* 请参见 include/linux/fs.h */ + char __user *buffer, /* 待填充数据的缓冲区 */ + size_t length, /* 缓冲区长度 */ + loff_t *offset) +{ + /* 实际写入缓冲区的字节数 */ + int bytes_read = 0; + const char *msg_ptr = msg; + + if (!*(msg_ptr + *offset)) { /* 已到达消息的末尾 */ + *offset = 0; /* 重置偏移量 */ + return 0; /* 表示文件结束 */ + } + + msg_ptr += *offset; + + /* 实际将数据放入缓冲区 */ + while (length && *msg_ptr) { + /* 缓冲区在用户数据段，而不是内核段所以直接赋值 "*" 是无效的 + * 我们必须使用 put_user 函数将数据从内核数据段复制到用户数据段 + */ + put_user(*(msg_ptr++), buffer++); + length--; + bytes_read++; + } + + *offset += bytes_read; + + /* 大多数读取函数返回放入缓冲区的字节数 */ + return bytes_read; +} + +/* 当进程写入dev文件时调用: echo "hi" > /dev/hello */ +static ssize_t device_write(struct file *filp, const char __user *buff, + size_t len, loff_t *off) +{ + pr_alert("对不起，不支持此操作.\n"); + return -EINVAL; +} + +module_init(chardev_init); +module_exit(chardev_exit); + +MODULE_LICENSE("GPL"); + diff --git a/示例/2-驱动相关文件/Makefile b/示例/2-驱动相关文件/Makefile new file mode 100644 index 0000000..834ce5b --- /dev/null +++ b/示例/2-驱动相关文件/Makefile @@ -0,0 +1,15 @@ +obj-m += procfs1.o +obj-m += procfs2.o +obj-m += procfs3.o +obj-m += procfs4.o +obj-m += hello-sysfs.o + +PWD := $(CURDIR) + +all: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules + gcc procfs.c -o 占位 + +clean: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean + rm 占位 diff --git a/示例/2-驱动相关文件/hello-sysfs.c b/示例/2-驱动相关文件/hello-sysfs.c new file mode 100644 index 0000000..5f18d33 --- /dev/null +++ b/示例/2-驱动相关文件/hello-sysfs.c @@ -0,0 +1,61 @@ +/* + * hello-sysfs.c sysfs 示例 + */ +#include +#include +#include +#include +#include +#include + +static struct kobject *mymodule; + +/* 你希望能够更改的变量 */ +static int myvariable = 0; + +static ssize_t myvariable_show(struct kobject *kobj, + struct kobj_attribute *attr, char *buf) +{ + return sprintf(buf, "%d\n", myvariable); +} + +static ssize_t myvariable_store(struct kobject *kobj, + struct kobj_attribute *attr, char *buf, + size_t count) +{ + sscanf(buf, "%du", &myvariable); + return count; +} + +static struct kobj_attribute myvariable_attribute = + __ATTR(myvariable, 0660, myvariable_show, (void *)myvariable_store); + +static int __init mymodule_init(void) +{ + int error = 0; + + pr_info("我的模块: 初始化完成\n"); + + mymodule = kobject_create_and_add("我的模块", kernel_kobj); + if (!mymodule) + return -ENOMEM; + + error = sysfs_create_file(mymodule, &myvariable_attribute.attr); + if (error) { + pr_info("在 /sys/kernel/我的模块 创建 myvariable 文件失败\n"); + } + + return error; +} + +static void __exit mymodule_exit(void) +{ + pr_info("我的模块: 退出成功\n"); + kobject_put(mymodule); +} + +module_init(mymodule_init); +module_exit(mymodule_exit); + +MODULE_LICENSE("GPL"); + diff --git a/示例/2-驱动相关文件/procfs.c b/示例/2-驱动相关文件/procfs.c new file mode 100644 index 0000000..ebb65bf --- /dev/null +++ b/示例/2-驱动相关文件/procfs.c @@ -0,0 +1,37 @@ +#include +#include +#include +#include + +int main() { + char procName[256]; + strcpy(procName, "/proc/buffer2k"); + int fd = open(procName, O_RDONLY); + if (fd < 0) { + perror("open"); + return 1; + } + + char buffer[256]; + ssize_t bytesRead = read(fd, buffer, sizeof(buffer) - 1); + if (bytesRead < 0) { + perror("read"); + close(fd); + return 1; + } + + int seconds = 30; + buffer[bytesRead] = '\0'; + printf("%s 内容: %s \n", procName, buffer, seconds); + + while (seconds > 0) { + printf("\r文件将在: %d 秒后关闭", seconds); + fflush(stdout); + sleep(1); + seconds--; + } + + close(fd); + printf("\r文件已关闭"); + return 0; +} diff --git a/示例/2-驱动相关文件/procfs1.c b/示例/2-驱动相关文件/procfs1.c new file mode 100644 index 0000000..9d20601 --- /dev/null +++ b/示例/2-驱动相关文件/procfs1.c @@ -0,0 +1,69 @@ +/* + * procfs1.c + */ + +#include +#include +#include +#include +#include + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0) +#define HAVE_PROC_OPS +#endif + +#define procfs_name "helloworld" + +static struct proc_dir_entry *our_proc_file; + +static ssize_t procfile_read(struct file *file_pointer, char __user *buffer, + size_t buffer_length, loff_t *offset) +{ + char s[13] = "HelloWorld!\n"; + int len = sizeof(s); + ssize_t ret = len; + /* 如果偏移量大于或等于字符串长度，或者 copy_to_user 失败，则读取操作失败，返回 0。 */ + if (*offset >= len || copy_to_user(buffer, s, len)) { + pr_info("copy_to_user 执行结束 \n"); + ret = 0; + } else { + pr_info("读取项目文件: %s\n", file_pointer->f_path.dentry->d_name.name); + *offset += len; + } + return ret; +} + +#ifdef HAVE_PROC_OPS +static const struct proc_ops proc_file_fops = { + .proc_read = procfile_read, +}; +#else +static const struct file_operations proc_file_fops = { + .read = procfile_read, +}; +#endif + +static int __init procfs1_init(void) +{ + our_proc_file = proc_create(procfs_name, 0644, NULL, &proc_file_fops); + if (NULL == our_proc_file) { + proc_remove(our_proc_file); + pr_alert("错误: 无法初始化 /proc/%s\n", procfs_name); + return -ENOMEM; + } + + pr_info("/proc/%s 已创建\n", procfs_name); + return 0; +} + +static void __exit procfs1_exit(void) +{ + proc_remove(our_proc_file); + pr_info("/proc/%s 已卸载\n", procfs_name); +} + +module_init(procfs1_init); +module_exit(procfs1_exit); + +MODULE_LICENSE("GPL"); + diff --git a/示例/2-驱动相关文件/procfs2.c b/示例/2-驱动相关文件/procfs2.c new file mode 100644 index 0000000..1f9a3a9 --- /dev/null +++ b/示例/2-驱动相关文件/procfs2.c @@ -0,0 +1,98 @@ +/* + * procfs2.c - 在/proc中创建一个 "文件" + */ + +#include +#include +#include /* 使用 procfs 时的必要模块 */ +#include /* 引入 copy_from_user */ +#include + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0) +#define HAVE_PROC_OPS +#endif + +#define PROCFS_MAX_SIZE 1024 +#define PROCFS_NAME "buffer1k" + +/* 此结构保存有关 /proc 文件的信息 */ +static struct proc_dir_entry *our_proc_file; + +/* 用于存储此模块字符的缓冲区 */ +static char procfs_buffer[PROCFS_MAX_SIZE]; + +/* 缓冲区的大小 */ +static unsigned long procfs_buffer_size = 0; + +/* 在读取 /proc 文件时调用该函数 */ +static ssize_t procfile_read(struct file *file_pointer, char __user *buffer, + size_t buffer_length, loff_t *offset) +{ + char s[13] = "HelloWorld!\n"; + int len = sizeof(s); + ssize_t ret = len; + + if (*offset >= len || copy_to_user(buffer, s, len)) { + pr_info("copy_to_user 执行结束 \n"); + ret = 0; + } else { + pr_info("读取项目文件: %s\n", file_pointer->f_path.dentry->d_name.name); + *offset += len; + } + + return ret; +} + +/* 在写入 /proc 文件时调用该函数 */ +static ssize_t procfile_write(struct file *file, const char __user *buff, + size_t len, loff_t *off) +{ + procfs_buffer_size = len; + if (procfs_buffer_size > PROCFS_MAX_SIZE) + procfs_buffer_size = PROCFS_MAX_SIZE; + + if (copy_from_user(procfs_buffer, buff, procfs_buffer_size)) + return -EFAULT; + + procfs_buffer[procfs_buffer_size & (PROCFS_MAX_SIZE - 1)] = '\0'; + *off += procfs_buffer_size; + pr_info("写入项目文件 %s\n", procfs_buffer); + + return procfs_buffer_size; +} + +#ifdef HAVE_PROC_OPS +static const struct proc_ops proc_file_fops = { + .proc_read = procfile_read, + .proc_write = procfile_write, +}; +#else +static const struct file_operations proc_file_fops = { + .read = procfile_read, + .write = procfile_write, +}; +#endif + +static int __init procfs2_init(void) +{ + our_proc_file = proc_create(PROCFS_NAME, 0644, NULL, &proc_file_fops); + if (NULL == our_proc_file) { + pr_alert("错误: 无法初始化 /proc/%s\n", PROCFS_NAME); + return -ENOMEM; + } + + pr_info("/proc/%s 已创建\n", PROCFS_NAME); + return 0; +} + +static void __exit procfs2_exit(void) +{ + proc_remove(our_proc_file); + pr_info("/proc/%s 已卸载\n", PROCFS_NAME); +} + +module_init(procfs2_init); +module_exit(procfs2_exit); + +MODULE_LICENSE("GPL"); + diff --git a/示例/2-驱动相关文件/procfs3.c b/示例/2-驱动相关文件/procfs3.c new file mode 100644 index 0000000..ec87c2f --- /dev/null +++ b/示例/2-驱动相关文件/procfs3.c @@ -0,0 +1,112 @@ +/* + * procfs3.c + */ + +#include +#include +#include +#include +#include +#include +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 10, 0) +#include +#endif + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0) +#define HAVE_PROC_OPS +#endif + +#define PROCFS_MAX_SIZE 2048UL +#define PROCFS_ENTRY_FILENAME "buffer2k" + +static struct proc_dir_entry *our_proc_file; +static char procfs_buffer[PROCFS_MAX_SIZE]; +static unsigned long procfs_buffer_size = 0; + +static ssize_t procfs_read(struct file *filp, char __user *buffer, + size_t length, loff_t *offset) +{ + if (*offset || procfs_buffer_size == 0) { + pr_notice("procfs_read: 结束\n"); + *offset = 0; + return 0; + } + procfs_buffer_size = min(procfs_buffer_size, length); + if (copy_to_user(buffer, procfs_buffer, procfs_buffer_size)) + return -EFAULT; + *offset += procfs_buffer_size; + + pr_notice("procfs_read: 读取 %lu 字节\n", procfs_buffer_size); + return procfs_buffer_size; +} +static ssize_t procfs_write(struct file *file, const char __user *buffer, + size_t len, loff_t *off) +{ + procfs_buffer_size = min(PROCFS_MAX_SIZE, len); + if (copy_from_user(procfs_buffer, buffer, procfs_buffer_size)) + return -EFAULT; + *off += procfs_buffer_size; + + pr_notice("procfs_write: 写入 %lu 字节\n", procfs_buffer_size); + return procfs_buffer_size; +} +static int procfs_open(struct inode *inode, struct file *file) +{ + try_module_get(THIS_MODULE); + pr_notice("procfs_open: 文件被打开, 目前文件正在被打开 -> %d \n", module_refcount(THIS_MODULE)); + return 0; +} +static int procfs_close(struct inode *inode, struct file *file) +{ + module_put(THIS_MODULE); + if (module_refcount(THIS_MODULE) == 0){ + pr_notice("procfs_close: 文件已全部关闭, 可以安全卸载\n"); + } else { + pr_notice("procfs_close: 文件剩余开启数为 -> %d \n", module_refcount(THIS_MODULE)); + } + return 0; +} + +#ifdef HAVE_PROC_OPS +static struct proc_ops file_ops_4_our_proc_file = { + .proc_read = procfs_read, + .proc_write = procfs_write, + .proc_open = procfs_open, + .proc_release = procfs_close, +}; +#else +static const struct file_operations file_ops_4_our_proc_file = { + .read = procfs_read, + .write = procfs_write, + .open = procfs_open, + .release = procfs_close, +}; +#endif + +static int __init procfs3_init(void) +{ + our_proc_file = proc_create(PROCFS_ENTRY_FILENAME, 0644, NULL, + &file_ops_4_our_proc_file); + if (our_proc_file == NULL) { + pr_notice("错误: 无法初始化 /proc/%s\n", + PROCFS_ENTRY_FILENAME); + return -ENOMEM; + } + proc_set_size(our_proc_file, 80); + proc_set_user(our_proc_file, GLOBAL_ROOT_UID, GLOBAL_ROOT_GID); + + pr_notice("/proc/%s 已创建\n", PROCFS_ENTRY_FILENAME); + return 0; +} + +static void __exit procfs3_exit(void) +{ + remove_proc_entry(PROCFS_ENTRY_FILENAME, NULL); + pr_notice("/proc/%s 已卸载\n", PROCFS_ENTRY_FILENAME); +} + +module_init(procfs3_init); +module_exit(procfs3_exit); + +MODULE_LICENSE("GPL"); + diff --git a/示例/2-驱动相关文件/procfs4.c b/示例/2-驱动相关文件/procfs4.c new file mode 100644 index 0000000..7798670 --- /dev/null +++ b/示例/2-驱动相关文件/procfs4.c @@ -0,0 +1,114 @@ +/* + * procfs4.c - 创建一个使用seq_file库来管理的/proc文件 + */ + +#include +#include +#include +#include /* 引入 seq_file */ +#include + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0) +#define HAVE_PROC_OPS +#endif + +#define PROC_NAME "iter" + +/* 这个函数在序列开始时被调用, 即: + * - 第一次读取 /proc 文件时 + * - 或在调用 stop 函数后（序列结束时） + */ +static void *my_seq_start(struct seq_file *s, loff_t *pos) +{ + static unsigned long counter = 0; + + /* 是否开始一个新的序列？ */ + if (*pos == 0) { + /* yes => 返回非 NULL 值以开始序列 */ + return &counter; + } + + /* no => 这是序列的结束，返回 NULL 以停止读取 */ + *pos = 0; + return NULL; +} + +/* 这个函数在序列开始后被调用。它会被调用直到返回 NULL(序列结束) */ +static void *my_seq_next(struct seq_file *s, void *v, loff_t *pos) +{ + unsigned long *tmp_v = (unsigned long *)v; + (*tmp_v)++; + (*pos)++; + return NULL; +} + +/* 这个函数在序列结束时被调用 */ +static void my_seq_stop(struct seq_file *s, void *v) +{ + /* 无需操作，因为我们在 start() 中使用了静态值 */ +} + +/* 这个函数在序列的每一步中被调用 */ +static int my_seq_show(struct seq_file *s, void *v) +{ + loff_t *spos = (loff_t *)v; + + seq_printf(s, "%Ld\n", *spos); + return 0; +} + +/* 这个结构体包含了管理序列的函数 */ +static struct seq_operations my_seq_ops = { + .start = my_seq_start, + .next = my_seq_next, + .stop = my_seq_stop, + .show = my_seq_show, +}; + +/* 这个函数在打开 /proc 文件时被调用 */ +static int my_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &my_seq_ops); +}; + +/* 这个结构体包含了管理 /proc 文件的函数 */ +#ifdef HAVE_PROC_OPS +static const struct proc_ops my_file_ops = { + .proc_open = my_open, + .proc_read = seq_read, + .proc_lseek = seq_lseek, + .proc_release = seq_release, +}; +#else +static const struct file_operations my_file_ops = { + .open = my_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; +#endif + +static int __init procfs4_init(void) +{ + struct proc_dir_entry *entry; + + entry = proc_create(PROC_NAME, 0, NULL, &my_file_ops); + if (entry == NULL) { + pr_debug("错误:无法初始化 /proc/%s\n", PROC_NAME); + return -ENOMEM; + } + + return 0; +} + +static void __exit procfs4_exit(void) +{ + remove_proc_entry(PROC_NAME, NULL); + pr_debug("/proc/%s 已移除\n", PROC_NAME); +} + +module_init(procfs4_init); +module_exit(procfs4_exit); + +MODULE_LICENSE("GPL"); + diff --git a/示例/3-ioctl/Makefile b/示例/3-ioctl/Makefile new file mode 100644 index 0000000..c714024 --- /dev/null +++ b/示例/3-ioctl/Makefile @@ -0,0 +1,14 @@ +obj-m += ioctl.o +obj-m += chardev2.o + + +PWD := $(CURDIR) + +all: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules + gcc userspace_ioctl.c -o 读写_用户空间 + +clean: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean + rm 读写_用户空间 + diff --git a/示例/3-ioctl/chardev.h b/示例/3-ioctl/chardev.h new file mode 100644 index 0000000..16c3424 --- /dev/null +++ b/示例/3-ioctl/chardev.h @@ -0,0 +1,37 @@ +/* + * chardev.h - 包含 ioctl 定义的头文件。 + * 这些声明必须放在头文件中，因为它们需要同时被内核模块（在 chardev2.c 中）和调用 ioctl() 的进程（在 userspace_ioctl.c 中）所知晓。 + */ + +#ifndef CHARDEV_H +#define CHARDEV_H + +#include + +/* 主设备号。由于 ioctl 需要知道主设备号，我们不能再依赖动态注册。 */ +#define MAJOR_NUM 100 + +/* 设置设备驱动的消息 */ +#define IOCTL_SET_MSG _IOW(MAJOR_NUM, 0, char *) +/* _IOW 表示我们正在创建一个 ioctl 命令，用于将信息从用户进程传递到内核模块。 + * 第一个参数 MAJOR_NUM 是我们使用的主设备号。 + * 第二个参数是命令的编号（可以有多个命令，含义不同）。 + * 第三个参数是我们希望从进程传递到内核的数据类型。 + */ + +/* 获取设备驱动的消息 */ +#define IOCTL_GET_MSG _IOR(MAJOR_NUM, 1, char *) +/* 此 IOCTL 用于输出，获取设备驱动的消息。 + * 需要一个缓冲区来存放消息，该缓冲区由进程分配。 + */ + +/* 获取消息的第 n 个字节 */ +#define IOCTL_GET_NTH_BYTE _IOWR(MAJOR_NUM, 2, int) +/* 此 IOCTL 用于输入和输出。它从用户获取一个数字 n，并返回消息的第 n 个字节。 + */ + +/* 设备文件的名称 */ +#define DEVICE_FILE_NAME "char_dev" +#define DEVICE_PATH "/dev/char_dev" + +#endif diff --git a/示例/3-ioctl/chardev2.c b/示例/3-ioctl/chardev2.c new file mode 100644 index 0000000..3cdc0d1 --- /dev/null +++ b/示例/3-ioctl/chardev2.c @@ -0,0 +1,207 @@ +/* + * chardev2.c - 创建一个输入/输出符的设备 + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include /* 引入 get_user 和 put_user */ +#include + +#include + +#include "chardev.h" +#define SUCCESS 0 +#define DEVICE_NAME "char_dev" +#define BUF_LEN 80 + +enum { + CDEV_NOT_USED = 0, + CDEV_EXCLUSIVE_OPEN = 1, +}; + +/* 设备当前是否已打开？用于防止对同一设备的并发访问 */ +static atomic_t already_open = ATOMIC_INIT(CDEV_NOT_USED); + +/* 设备在被请求时返回的消息 */ +static char message[BUF_LEN + 1]; + +static struct class *cls; + +/* 当进程尝试打开设备文件时调用此函数 */ +static int device_open(struct inode *inode, struct file *file) +{ + pr_info("[device_open]打开: (%p)\n", file); + + try_module_get(THIS_MODULE); + return SUCCESS; +} + +static int device_release(struct inode *inode, struct file *file) +{ + pr_info("[device_release]释放: (%p,%p)\n", inode, file); + + module_put(THIS_MODULE); + return SUCCESS; +} + +/* 打开设备文件的进程尝试从中读取数据时调用此函数 */ +static ssize_t device_read(struct file *file, /* 参见include/linux/fs.h */ + char __user *buffer, /* 要填充的用户缓冲区 */ + size_t length, /* 缓冲区的长度 */ + loff_t *offset) +{ + /* 实际写入到缓冲区的字节数 */ + int bytes_read = 0; + /* 读取消息的进度指针，如果消息比缓冲区大，这很有用 */ + const char *message_ptr = message; + + if (!*(message_ptr + *offset)) { /* 到达消息末尾 */ + *offset = 0; /* 重置偏移量 */ + return 0; /* 表示文件结束 */ + } + + message_ptr += *offset; + /* 实际将数据写入缓冲区 */ + while (length && *message_ptr) { + /* 由于缓冲区在用户数据段而非内核数据段，需要使用 put_user 将数据从内核复制到用户空间 */ + put_user(*(message_ptr++), buffer++); + length--; + bytes_read++; + } + + pr_info("读取 %d 字节, %ld 字节剩余\n", bytes_read, length); + + *offset += bytes_read; + + /* 读取函数应返回实际写入缓冲区的字节数 */ + return bytes_read; +} + +/* 当有人尝试向我们的设备文件写入数据时调用此函数 */ +static ssize_t device_write(struct file *file, const char __user *buffer, + size_t length, loff_t *offset) +{ + int i; + + pr_info("[device_write]写入: %p,%p,%ld", file, buffer, length); + + /* 将数据从用户空间缓冲区读取到内核空间的 message 中 */ + for (i = 0; i < length && i < BUF_LEN; i++) + get_user(message[i], buffer + i); + + /* 返回实际写入 message 中的字符数 */ + return i; +} + +/* 当进程尝试对设备文件执行 ioctl 操作时调用此函数。除了 inode 和 file 结构外，我们还接收到两个额外的参数：ioctl 的编号和传递给 ioctl 的参数。 + * 如果 ioctl 是写操作或读/写操作（即返回输出给调用进程），ioctl 调用将返回此函数的输出。 + */ +static long +device_ioctl(struct file *file, + unsigned int ioctl_num, /* ioctl 操作编号 */ + unsigned long ioctl_param) /* ioctl 参数 */ +{ + int i; + long ret = SUCCESS; + + /* 不允许同时与两个进程交互 */ + if (atomic_cmpxchg(&already_open, CDEV_NOT_USED, CDEV_EXCLUSIVE_OPEN)) + return -EBUSY; + + /* 根据 ioctl 操作编号进行切换 */ + switch (ioctl_num) { + case IOCTL_SET_MSG: { + /* 接收一个用户空间的消息指针，并将其设置为设备的消息 */ + char __user *tmp = (char __user *)ioctl_param; + char ch; + + /* 查找消息的长度 */ + get_user(ch, tmp); + for (i = 0; ch && i < BUF_LEN; i++, tmp++) + get_user(ch, tmp); + + device_write(file, (char __user *)ioctl_param, i, NULL); + break; + } + case IOCTL_GET_MSG: { + loff_t offset = 0; + + /* 将当前消息返回给调用进程，参数是一个指针，将数据填充到该指针指向的缓冲区中 */ + i = device_read(file, (char __user *)ioctl_param, 99, &offset); + + /* 在缓冲区末尾添加一个终止符 */ + put_user('\0', (char __user *)ioctl_param + i); + break; + } + case IOCTL_GET_NTH_BYTE: + /* 这个 ioctl 同时用于输入（ioctl_param）和输出（函数的返回值） */ + ret = (long)message[ioctl_param]; + break; + } + + /* 准备好接待下一个调用者 */ + atomic_set(&already_open, CDEV_NOT_USED); + + return ret; +} + +/* 模块声明 */ + +/* 这个结构体将保存当进程对我们创建的设备进行操作时调用的函数。 + * 由于指向这个结构体的指针被保存在设备表中，它不能是 init_module 的局部变量。 + * NULL 表示未实现的函数。 + */ +static struct file_operations fops = { + .read = device_read, + .write = device_write, + .unlocked_ioctl = device_ioctl, + .open = device_open, + .release = device_release, /* 类似 关闭`close` 操作 */ +}; + +/* 初始化模块-注册字符设备 */ +static int __init chardev2_init(void) +{ + /* 注册字符设备(尝试一下) */ + int ret_val = register_chrdev(MAJOR_NUM, DEVICE_NAME, &fops); + + /* 出现负值代表有个错误 */ + if (ret_val < 0) { + pr_alert("注册字符设备 %d 失败\n", ret_val); + return ret_val; + } + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 0) + cls = class_create(DEVICE_FILE_NAME); +#else + cls = class_create(THIS_MODULE, DEVICE_FILE_NAME); +#endif + device_create(cls, NULL, MKDEV(MAJOR_NUM, 0), NULL, DEVICE_FILE_NAME); + + pr_info("设备创建于 /dev/%s\n", DEVICE_FILE_NAME); + + return 0; +} + +/* 清理模块 - 从/proc注销移除相关文件 */ +static void __exit chardev2_exit(void) +{ + device_destroy(cls, MKDEV(MAJOR_NUM, 0)); + class_destroy(cls); + + /* 注销设备 */ + unregister_chrdev(MAJOR_NUM, DEVICE_NAME); +} + +module_init(chardev2_init); +module_exit(chardev2_exit); + +MODULE_LICENSE("GPL"); + diff --git a/示例/3-ioctl/ioctl.c b/示例/3-ioctl/ioctl.c new file mode 100644 index 0000000..7af7179 --- /dev/null +++ b/示例/3-ioctl/ioctl.c @@ -0,0 +1,212 @@ +/* + * ioctl.c + */ +#include +#include +#include +#include +#include +#include +#include +#include + +// 定义用于 ioctl 操作的数据结构 +struct ioctl_arg { + unsigned int val; +}; + +// 定义 ioctl 操作的宏 +/* Documentation/userspace-api/ioctl/ioctl-number.rst */ +#define IOC_MAGIC '\x66' // 自定义的魔术数字，用于标识 ioctl 操作的类别 + +// 定义不同的 ioctl 操作 +#define IOCTL_VALSET _IOW(IOC_MAGIC, 0, struct ioctl_arg) // 写操作，设置一个值 +#define IOCTL_VALGET _IOR(IOC_MAGIC, 1, struct ioctl_arg) // 读操作，获取一个值 +#define IOCTL_VALGET_NUM _IOR(IOC_MAGIC, 2, int) // 读操作，获取一个整数 +#define IOCTL_VALSET_NUM _IOW(IOC_MAGIC, 3, int) // 写操作，设置一个整数 + +#define IOCTL_VAL_MAXNR 3 // 最大的 ioctl 命令号 +#define DRIVER_NAME "ioctltest" // 驱动名称 + +// 定义一些全局变量 +static unsigned int test_ioctl_major = 0; // 主设备号 +static unsigned int num_of_dev = 1; // 设备数量 +static struct cdev test_ioctl_cdev; // 字符设备结构体 +static int ioctl_num = 0; // 用于存储整数值的全局变量 + +// 定义用于保存设备数据的结构体 +struct test_ioctl_data { + unsigned char val; // 存储一个值 + rwlock_t lock; // 读写锁，用于保护数据的并发访问 +}; + +// 处理 ioctl 操作的函数 +static long test_ioctl_ioctl(struct file *filp, unsigned int cmd, + unsigned long arg) +{ + struct test_ioctl_data *ioctl_data = filp->private_data; // 从文件私有数据中获取设备数据 + int retval = 0; // 操作结果 + unsigned char val; + struct ioctl_arg data; + memset(&data, 0, sizeof(data)); // 清空 data 结构体 + + switch (cmd) { + case IOCTL_VALSET: + // 处理 IOCTL_VALSET 命令，将用户空间的数据复制到内核空间 + if (copy_from_user(&data, (int __user *)arg, sizeof(data))) { + retval = -EFAULT; + goto done; + } + + pr_alert("IOCTL 设置值:%x .\n", data.val); // 打印设置的值 + write_lock(&ioctl_data->lock); // 获取写锁 + ioctl_data->val = data.val; // 更新设备数据 + write_unlock(&ioctl_data->lock); // 释放写锁 + break; + + case IOCTL_VALGET: + // 处理 IOCTL_VALGET 命令，将内核空间的数据复制到用户空间 + read_lock(&ioctl_data->lock); // 获取读锁 + val = ioctl_data->val; // 读取设备数据 + read_unlock(&ioctl_data->lock); // 释放读锁 + data.val = val; + + if (copy_to_user((int __user *)arg, &data, sizeof(data))) { + retval = -EFAULT; // 复制失败 + goto done; + } + + break; + + case IOCTL_VALGET_NUM: + // 处理 IOCTL_VALGET_NUM 命令，将整数值返回给用户空间 + retval = __put_user(ioctl_num, (int __user *)arg); + break; + + case IOCTL_VALSET_NUM: + // 处理 IOCTL_VALSET_NUM 命令，从用户空间获取整数值 + ioctl_num = arg; + break; + + default: + retval = -ENOTTY; // 命令不被支持 + } + +done: + return retval; // 返回操作结果 +} + +// 处理文件读取操作的函数 +static ssize_t test_ioctl_read(struct file *filp, char __user *buf, + size_t count, loff_t *f_pos) +{ + struct test_ioctl_data *ioctl_data = filp->private_data; // 从文件私有数据中获取设备数据 + unsigned char val; + int retval; + int i = 0; + + read_lock(&ioctl_data->lock); // 获取读锁 + val = ioctl_data->val; // 读取设备数据 + read_unlock(&ioctl_data->lock); // 释放读锁 + + // 将数据从内核空间复制到用户空间 + for (; i < count; i++) { + if (copy_to_user(&buf[i], &val, 1)) { + retval = -EFAULT; // 复制失败 + goto out; + } + } + + retval = count; // 成功读取的字节数 +out: + return retval; // 返回读取结果 +} + +// 处理文件关闭操作的函数 +static int test_ioctl_close(struct inode *inode, struct file *filp) +{ + pr_alert("%s 呼叫\n", __func__); // 打印函数名 + + if (filp->private_data) { + kfree(filp->private_data); // 释放内存 + filp->private_data = NULL; + } + + return 0; // 成功关闭文件 +} + +// 处理文件打开操作的函数 +static int test_ioctl_open(struct inode *inode, struct file *filp) +{ + struct test_ioctl_data *ioctl_data; + + pr_alert("%s 呼叫\n", __func__); // 打印函数名 + ioctl_data = kmalloc(sizeof(struct test_ioctl_data), GFP_KERNEL); // 分配内存 + + if (ioctl_data == NULL) + return -ENOMEM; // 内存分配失败 + + rwlock_init(&ioctl_data->lock); // 初始化读写锁 + ioctl_data->val = 0xFF; // 初始化设备数据 + filp->private_data = ioctl_data; // 将设备数据指针保存到文件私有数据中 + + return 0; +} + +// 文件操作结构体，定义了设备文件的操作函数 +static struct file_operations fops = { +#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 4, 0) + .owner = THIS_MODULE, // 设置模块所有者 +#endif + .open = test_ioctl_open, // 打开文件操作函数 + .release = test_ioctl_close, // 关闭文件操作函数 + .read = test_ioctl_read, // 读取文件操作函数 + .unlocked_ioctl = test_ioctl_ioctl, // ioctl 操作函数 +}; + +// 模块初始化函数 +static int __init ioctl_init(void) +{ + dev_t dev; + int alloc_ret = -1; + int cdev_ret = -1; + // 分配字符设备号 + alloc_ret = alloc_chrdev_region(&dev, 0, num_of_dev, DRIVER_NAME); + + if (alloc_ret) + goto error; // 分配失败，跳转到错误处理 + + test_ioctl_major = MAJOR(dev); // 获取主设备号 + cdev_init(&test_ioctl_cdev, &fops); // 初始化字符设备结构体 + cdev_ret = cdev_add(&test_ioctl_cdev, dev, num_of_dev); // 添加字符设备 + + if (cdev_ret) + goto error; // 添加失败，跳转到错误处理 + + pr_alert("%s 驱动(主编号: %d) 已安装\n", DRIVER_NAME, + test_ioctl_major); // 打印安装成功信息 + return 0; +error: + if (cdev_ret == 0) + cdev_del(&test_ioctl_cdev); // 释放字符设备 + if (alloc_ret == 0) + unregister_chrdev_region(dev, num_of_dev); // 释放设备号 + return -1; +} + +// 模块卸载函数 +static void __exit ioctl_exit(void) +{ + dev_t dev = MKDEV(test_ioctl_major, 0); // 创建 dev_t 变量 + + cdev_del(&test_ioctl_cdev); // 删除字符设备 + unregister_chrdev_region(dev, num_of_dev); // 释放字符设备号 + pr_alert("%s 模块卸载 \n", DRIVER_NAME); // 打印卸载信息 +} + +module_init(ioctl_init); +module_exit(ioctl_exit); + +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("这是 ioctl 测试模块"); + diff --git a/示例/3-ioctl/userspace_ioctl.c b/示例/3-ioctl/userspace_ioctl.c new file mode 100644 index 0000000..e74834b --- /dev/null +++ b/示例/3-ioctl/userspace_ioctl.c @@ -0,0 +1,103 @@ +/* userspace_ioctl.c - 用于通过 ioctl 控制内核模块的进程 + * + * 之前我们可以使用 cat 进行输入和输出，但现在需要使用 ioctl，这要求我们编写自己的进程。 + */ + +/* 包含设备特定的信息，如 ioctl 编号和主设备号。 */ +#include "./chardev.h" + +#include /* 标准输入/输出 */ +#include /* 打开文件 */ +#include /* 关闭文件 */ +#include /* 退出程序 */ +#include /* ioctl 调用 */ + +/* ioctl 调用的函数 */ + +int ioctl_set_msg(int file_desc, char *message) +{ + int ret_val; + + ret_val = ioctl(file_desc, IOCTL_SET_MSG, message); + + if (ret_val < 0) { + printf("ioctl_set_msg 失败: %d\n", ret_val); + } + + return ret_val; +} + +int ioctl_get_msg(int file_desc) +{ + int ret_val; + char message[100] = { 0 }; + + /* 警告 - 这里存在风险，因为我们没有告知内核写入的缓冲区长度，可能会导致缓冲区溢出。在实际生产程序中， + * 我们应该使用两个 ioctl 调用 - 一个告知内核缓冲区长度，另一个提供要填充的缓冲区。 + */ + ret_val = ioctl(file_desc, IOCTL_GET_MSG, message); + + if (ret_val < 0) { + printf("ioctl_get_msg 失败: %d\n", ret_val); + } + printf("获取的消息: %s", message); + + return ret_val; +} + +/* 注意:这种按字节读取消息的方式无法正常读取中文 */ +int ioctl_get_nth_byte(int file_desc) +{ + int i, c, err; + + printf("按字节获取到的消息: "); + err = 0; + i = 0; + do { + c = ioctl(file_desc, IOCTL_GET_NTH_BYTE, i++); + + if (c < 0) { + err = 1; + continue; + } + putchar(c); + } while (c != 0); + + if (err == 1){ + printf("(非ascii字符已被省略)\n\n"); + } + + return 0; +} + +/* 主函数 - 调用 ioctl 函数 */ +int main(void) +{ + int file_desc, ret_val; + char *msg = "通过 ioctl 传递的消息\n"; + /* char *msg = "qwer1234\n"; */ + + file_desc = open(DEVICE_PATH, O_RDWR); + if (file_desc < 0) { + printf("无法打开设备文件: %s, 错误: %d\n", DEVICE_PATH, file_desc); + exit(EXIT_FAILURE); + } + + ret_val = ioctl_set_msg(file_desc, msg); + if (ret_val) + goto error; + ret_val = ioctl_get_nth_byte(file_desc); + if (ret_val) + goto error; + ret_val = ioctl_get_msg(file_desc); + if (ret_val) + goto error; + + close(file_desc); + return 0; + +error: + close(file_desc); + exit(EXIT_FAILURE); +} + diff --git a/示例/4-系统调用/Makefile b/示例/4-系统调用/Makefile new file mode 100644 index 0000000..f200eca --- /dev/null +++ b/示例/4-系统调用/Makefile @@ -0,0 +1,11 @@ +obj-m += syscall-steal_loong64.o + + +PWD := $(CURDIR) + +all: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules + +clean: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean + diff --git a/示例/4-系统调用/syscall-steal_loong64.c b/示例/4-系统调用/syscall-steal_loong64.c new file mode 100644 index 0000000..9cd0fd9 --- /dev/null +++ b/示例/4-系统调用/syscall-steal_loong64.c @@ -0,0 +1,275 @@ +/* + * syscall-steal.c + * 系统调用 "监视" 示例(龙架构专用)。 + * 通过更改 fcsr 寄存器中的第 16 位，在处理器级别禁用页面保护 + */ + +#include +#include +#include +#include /* 包含一些参数 */ +#include /* 系统调用列表 */ +#include /* 引入 current_uid() */ +#include /* 引入 __kuid_val() */ +#include + +/* 根据本程序的需求我们需要了解当前用户是谁 */ +#include +#include + +/* 访问“sys_call_table”的方式随着内核内部的变化而变化。 + * 内核版本 <= v5.4 : 手动符号查找 + * 内核版本 == v5.5 或 v5.6 : 使用 kallsyms_lookup_name() + * 内核版本 >= v5.7 : Kprobes 或特定的内核模块参数 + */ + +/* 在 Linux v5.11 及以上版本中，内核调用 ksys_close() 的方式被移除 */ +#if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 7, 0)) + +#if LINUX_VERSION_CODE <= KERNEL_VERSION(5, 4, 0) +#define HAVE_KSYS_CLOSE 1 +#include /* 引入 ksys_close() */ +#else +#include /* 引入 kallsyms_lookup_name */ +#endif + +#else + +#if defined(CONFIG_KPROBES) +#define HAVE_KPROBES 1 +#if defined(CONFIG_X86_64) +/* 如果你尝试使用系统调用表来拦截系统调用但未成功，你可以尝试使用 Kprobes 来拦截系统调用。 + * 将 USE_KPROBES_PRE_HANDLER_BEFORE_SYSCALL 设置为 1 以注册一个预处理程序在系统调用之前。 + */ +#define USE_KPROBES_PRE_HANDLER_BEFORE_SYSCALL 0 +#endif +#include +#else +#define HAVE_PARAM 1 +#include /* 引入 sprint_symbol */ +/* sys_call_table 的地址可以通过查看 "/boot/System.map" 或 "/proc/kallsyms" 获得。 + * 当内核版本为 v5.7 及以上时，如果没有 CONFIG_KPROBES，你可以输入参数或者模块会查找所有内存。 + */ +static unsigned long sym = 0; +module_param(sym, ulong, 0644); +#endif /* CONFIG_KPROBES */ + +#endif /* 版本 < v5.7 */ + +/* 我们想要监视的 UID - 将从命令行填充。 */ +static uid_t uid = -1; +module_param(uid, int, 0644); + +#if USE_KPROBES_PRE_HANDLER_BEFORE_SYSCALL + +/* syscall_sym 是要监视的系统调用的符号名称。默认值为"__x64_sys_openat" + * 可以通过模块参数进行更改。你可以在 /proc/kallsyms 中查找系统调用的符号名称。 + */ +static char *syscall_sym = "__x64_sys_openat"; +module_param(syscall_sym, charp, 0644); + +static int sys_call_kprobe_pre_handler(struct kprobe *p, struct pt_regs *regs) +{ + if (__kuid_val(current_uid()) != uid) { + return 0; + } + + pr_info("%s 被 %d 调用\n", syscall_sym, uid); + return 0; +} + +static struct kprobe syscall_kprobe = { + .symbol_name = "__x64_sys_openat", + .pre_handler = sys_call_kprobe_pre_handler, +}; +#else + +static unsigned long **sys_call_table_stolen; + +/* 指向原始系统调用的指针。我们保留这个指针，而不是直接调用原始函数 (sys_openat)，是因为可能有其他模块在我们之前已经替换了系统调用。 + * 注意，这不是 100% 安全的，因为如果其他模块在我们之前替换了 sys_openat，那么当我们插入时，我们将调用那个模块中的函数 - + * 而且那个模块可能在我们之前已经被移除。 + * + * 另一个原因是我们无法获取 sys_openat。它是一个静态变量，因此没有被导出。 + */ +#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER +static asmlinkage long (*original_call)(const struct pt_regs *); +#else +static asmlinkage long (*original_call)(int, const char __user *, int, umode_t); +#endif + +/* 我们将用来替换 sys_openat (即调用 open 系统调用时调用的函数)的函数 + * 为了找到准确的原型，包含参数的数量和类型，我们首先找到原始函数(它位于 fs/open.c 文件中) + * + * 理论上，这意味着我们绑定于当前版本的内核。实际上，系统调用几乎不会改变 + * (因为系统调用是内核和进程之间的接口，如果系统调用发生变化，会引起混乱并需要重新编译程序) + */ +#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER +static asmlinkage long our_sys_openat(const struct pt_regs *regs) +#else +static asmlinkage long our_sys_openat(int dfd, const char __user *filename, + int flags, umode_t mode) +#endif +{ + int i = 0; + char ch; + + if (__kuid_val(current_uid()) != uid) + goto orig_call; + + /* 报告相关文件 */ + pr_info("Opened file by %d: ", uid); + do { +#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER + get_user(ch, (char __user *)regs->si + i); +#else + get_user(ch, (char __user *)filename + i); +#endif + i++; + pr_info("%c", ch); + } while (ch != 0); + pr_info("\n"); + +orig_call: + /* 调用原始的sys_openat-否则，我们将失去打开文件的能力 */ +#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER + return original_call(regs); +#else + return original_call(dfd, filename, flags, mode); +#endif +} + +static unsigned long **acquire_sys_call_table(void) +{ +#ifdef HAVE_KSYS_CLOSE + unsigned long int offset = PAGE_OFFSET; + unsigned long **sct; + + while (offset < ULLONG_MAX) { + sct = (unsigned long **)offset; + + if (sct[__NR_close] == (unsigned long *)ksys_close) + return sct; + + offset += sizeof(void *); + } + + return NULL; +#endif + +#ifdef HAVE_PARAM + const char sct_name[15] = "sys_call_table"; + char symbol[40] = { 0 }; + + if (sym == 0) { + pr_alert("对于 Linux v5.7 以上版本，Kprobes 是获取符号的首选方法\n"); + pr_info("如果没有 Kprobes，则必须指定 sys_call_table 符号的地址\n"); + pr_info("通过 /boot/System.map 或 /proc/kallsyms 将包含所有符号地址的符号转换为sym参数\n"); + return NULL; + } + sprint_symbol(symbol, sym); + if (!strncmp(sct_name, symbol, sizeof(sct_name) - 1)) + return (unsigned long **)sym; + + return NULL; +#endif + +#ifdef HAVE_KPROBES + unsigned long (*kallsyms_lookup_name)(const char *name); + struct kprobe kp = { + .symbol_name = "kallsyms_lookup_name", + }; + + if (register_kprobe(&kp) < 0) + return NULL; + kallsyms_lookup_name = (unsigned long (*)(const char *name))kp.addr; + unregister_kprobe(&kp); +#endif + + return (unsigned long **)kallsyms_lookup_name("sys_call_table"); +} + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 3, 0) +static inline void __write_fcsr(unsigned long fcsr) +{ + asm volatile("mov %0,%%fcsr" : "+r"(fcsr) : : "memory"); +} +#else +#define __write_fcsr write_fcsr +#endif + +static void enable_write_protection(void) +{ + unsigned long fcsr = read_fcsr(); + set_bit(16, &fcsr); + __write_fcsr(fcsr); +} + +static void disable_write_protection(void) +{ + unsigned long fcsr = read_fcsr(); + clear_bit(16, &fcsr); + __write_fcsr(fcsr); +} +#endif + +static int __init syscall_steal_start(void) +{ +#if USE_KPROBES_PRE_HANDLER_BEFORE_SYSCALL + + int err; + /* use symbol name from the module parameter */ + syscall_kprobe.symbol_name = syscall_sym; + err = register_kprobe(&syscall_kprobe); + if (err) { + pr_err("register_kprobe() 在 %s 失败: %d\n", syscall_sym, err); + pr_err("请检查 “syscall_sym ”参数中的符号名称\n"); + return err; + } + +#else + if (!(sys_call_table_stolen = acquire_sys_call_table())) + return -1; + + disable_write_protection(); + + /* 跟踪原始的打开函数 */ + original_call = (void *)sys_call_table_stolen[__NR_openat]; + + /* 请改用我们的openat函数 */ + sys_call_table_stolen[__NR_openat] = (unsigned long *)our_sys_openat; + + enable_write_protection(); + +#endif + + pr_info("监视 UID:%d\n", uid); + return 0; +} + +static void __exit syscall_steal_end(void) +{ +#if USE_KPROBES_PRE_HANDLER_BEFORE_SYSCALL + unregister_kprobe(&syscall_kprobe); +#else + if (!sys_call_table_stolen) + return; + + /* 将系统调用恢复正常 */ + if (sys_call_table_stolen[__NR_openat] != (unsigned long *)our_sys_openat) { + pr_alert("发现系统调用被其他人修改"); + pr_alert("系统可能处于不稳定状态"); + } + + disable_write_protection(); + sys_call_table_stolen[__NR_openat] = (unsigned long *)original_call; + enable_write_protection(); +#endif + + msleep(2000); +} + +module_init(syscall_steal_start); +module_exit(syscall_steal_end); + +MODULE_LICENSE("GPL"); diff --git a/示例/4-系统调用/syscall-steal_x86.c b/示例/4-系统调用/syscall-steal_x86.c new file mode 100644 index 0000000..cdfb64b --- /dev/null +++ b/示例/4-系统调用/syscall-steal_x86.c @@ -0,0 +1,275 @@ +/* + * syscall-steal.c + * 系统调用 "监视" 示例。 + * 通过更改 cr0 寄存器中的第 16 位，在处理器级别禁用页面保护(可能与 Intel 有关) + */ + +#include +#include +#include +#include /* 包含一些参数 */ +#include /* 系统调用列表 */ +#include /* 引入 current_uid() */ +#include /* 引入 __kuid_val() */ +#include + +/* 根据本程序的需求我们需要了解当前用户是谁 */ +#include +#include + +/* 访问“sys_call_table”的方式随着内核内部的变化而变化。 + * 内核版本 <= v5.4 : 手动符号查找 + * 内核版本 == v5.5 或 v5.6 : 使用 kallsyms_lookup_name() + * 内核版本 >= v5.7 : Kprobes 或特定的内核模块参数 + */ + +/* 在 Linux v5.11 及以上版本中，内核调用 ksys_close() 的方式被移除 */ +#if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 7, 0)) + +#if LINUX_VERSION_CODE <= KERNEL_VERSION(5, 4, 0) +#define HAVE_KSYS_CLOSE 1 +#include /* 引入 ksys_close() */ +#else +#include /* 引入 kallsyms_lookup_name */ +#endif + +#else + +#if defined(CONFIG_KPROBES) +#define HAVE_KPROBES 1 +#if defined(CONFIG_X86_64) +/* 如果你尝试使用系统调用表来拦截系统调用但未成功，你可以尝试使用 Kprobes 来拦截系统调用。 + * 将 USE_KPROBES_PRE_HANDLER_BEFORE_SYSCALL 设置为 1 以注册一个预处理程序在系统调用之前。 + */ +#define USE_KPROBES_PRE_HANDLER_BEFORE_SYSCALL 0 +#endif +#include +#else +#define HAVE_PARAM 1 +#include /* 引入 sprint_symbol */ +/* sys_call_table 的地址可以通过查看 "/boot/System.map" 或 "/proc/kallsyms" 获得。 + * 当内核版本为 v5.7 及以上时，如果没有 CONFIG_KPROBES，你可以输入参数或者模块会查找所有内存。 + */ +static unsigned long sym = 0; +module_param(sym, ulong, 0644); +#endif /* CONFIG_KPROBES */ + +#endif /* 版本 < v5.7 */ + +/* 我们想要监视的 UID - 将从命令行填充。 */ +static uid_t uid = -1; +module_param(uid, int, 0644); + +#if USE_KPROBES_PRE_HANDLER_BEFORE_SYSCALL + +/* syscall_sym 是要监视的系统调用的符号名称。默认值为"__x64_sys_openat" + * 可以通过模块参数进行更改。你可以在 /proc/kallsyms 中查找系统调用的符号名称。 + */ +static char *syscall_sym = "__x64_sys_openat"; +module_param(syscall_sym, charp, 0644); + +static int sys_call_kprobe_pre_handler(struct kprobe *p, struct pt_regs *regs) +{ + if (__kuid_val(current_uid()) != uid) { + return 0; + } + + pr_info("%s 被 %d 调用\n", syscall_sym, uid); + return 0; +} + +static struct kprobe syscall_kprobe = { + .symbol_name = "__x64_sys_openat", + .pre_handler = sys_call_kprobe_pre_handler, +}; +#else + +static unsigned long **sys_call_table_stolen; + +/* 指向原始系统调用的指针。我们保留这个指针，而不是直接调用原始函数 (sys_openat)，是因为可能有其他模块在我们之前已经替换了系统调用。 + * 注意，这不是 100% 安全的，因为如果其他模块在我们之前替换了 sys_openat，那么当我们插入时，我们将调用那个模块中的函数 - + * 而且那个模块可能在我们之前已经被移除。 + * + * 另一个原因是我们无法获取 sys_openat。它是一个静态变量，因此没有被导出。 + */ +#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER +static asmlinkage long (*original_call)(const struct pt_regs *); +#else +static asmlinkage long (*original_call)(int, const char __user *, int, umode_t); +#endif + +/* 我们将用来替换 sys_openat (即调用 open 系统调用时调用的函数)的函数 + * 为了找到准确的原型，包含参数的数量和类型，我们首先找到原始函数(它位于 fs/open.c 文件中) + * + * 理论上，这意味着我们绑定于当前版本的内核。实际上，系统调用几乎不会改变 + * (因为系统调用是内核和进程之间的接口，如果系统调用发生变化，会引起混乱并需要重新编译程序) + */ +#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER +static asmlinkage long our_sys_openat(const struct pt_regs *regs) +#else +static asmlinkage long our_sys_openat(int dfd, const char __user *filename, + int flags, umode_t mode) +#endif +{ + int i = 0; + char ch; + + if (__kuid_val(current_uid()) != uid) + goto orig_call; + + /* 报告相关文件 */ + pr_info("Opened file by %d: ", uid); + do { +#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER + get_user(ch, (char __user *)regs->si + i); +#else + get_user(ch, (char __user *)filename + i); +#endif + i++; + pr_info("%c", ch); + } while (ch != 0); + pr_info("\n"); + +orig_call: + /* 调用原始的sys_openat-否则，我们将失去打开文件的能力 */ +#ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER + return original_call(regs); +#else + return original_call(dfd, filename, flags, mode); +#endif +} + +static unsigned long **acquire_sys_call_table(void) +{ +#ifdef HAVE_KSYS_CLOSE + unsigned long int offset = PAGE_OFFSET; + unsigned long **sct; + + while (offset < ULLONG_MAX) { + sct = (unsigned long **)offset; + + if (sct[__NR_close] == (unsigned long *)ksys_close) + return sct; + + offset += sizeof(void *); + } + + return NULL; +#endif + +#ifdef HAVE_PARAM + const char sct_name[15] = "sys_call_table"; + char symbol[40] = { 0 }; + + if (sym == 0) { + pr_alert("对于 Linux v5.7 以上版本，Kprobes 是获取符号的首选方法\n"); + pr_info("如果没有 Kprobes，则必须指定 sys_call_table 符号的地址\n"); + pr_info("通过 /boot/System.map 或 /proc/kallsyms 将包含所有符号地址的符号转换为sym参数\n"); + return NULL; + } + sprint_symbol(symbol, sym); + if (!strncmp(sct_name, symbol, sizeof(sct_name) - 1)) + return (unsigned long **)sym; + + return NULL; +#endif + +#ifdef HAVE_KPROBES + unsigned long (*kallsyms_lookup_name)(const char *name); + struct kprobe kp = { + .symbol_name = "kallsyms_lookup_name", + }; + + if (register_kprobe(&kp) < 0) + return NULL; + kallsyms_lookup_name = (unsigned long (*)(const char *name))kp.addr; + unregister_kprobe(&kp); +#endif + + return (unsigned long **)kallsyms_lookup_name("sys_call_table"); +} + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 3, 0) +static inline void __write_cr0(unsigned long cr0) +{ + asm volatile("mov %0,%%cr0" : "+r"(cr0) : : "memory"); +} +#else +#define __write_cr0 write_cr0 +#endif + +static void enable_write_protection(void) +{ + unsigned long cr0 = read_cr0(); + set_bit(16, &cr0); + __write_cr0(cr0); +} + +static void disable_write_protection(void) +{ + unsigned long cr0 = read_cr0(); + clear_bit(16, &cr0); + __write_cr0(cr0); +} +#endif + +static int __init syscall_steal_start(void) +{ +#if USE_KPROBES_PRE_HANDLER_BEFORE_SYSCALL + + int err; + /* use symbol name from the module parameter */ + syscall_kprobe.symbol_name = syscall_sym; + err = register_kprobe(&syscall_kprobe); + if (err) { + pr_err("register_kprobe() 在 %s 失败: %d\n", syscall_sym, err); + pr_err("请检查 “syscall_sym ”参数中的符号名称\n"); + return err; + } + +#else + if (!(sys_call_table_stolen = acquire_sys_call_table())) + return -1; + + disable_write_protection(); + + /* 跟踪原始的打开函数 */ + original_call = (void *)sys_call_table_stolen[__NR_openat]; + + /* 请改用我们的openat函数 */ + sys_call_table_stolen[__NR_openat] = (unsigned long *)our_sys_openat; + + enable_write_protection(); + +#endif + + pr_info("监视 UID:%d\n", uid); + return 0; +} + +static void __exit syscall_steal_end(void) +{ +#if USE_KPROBES_PRE_HANDLER_BEFORE_SYSCALL + unregister_kprobe(&syscall_kprobe); +#else + if (!sys_call_table_stolen) + return; + + /* 将系统调用恢复正常 */ + if (sys_call_table_stolen[__NR_openat] != (unsigned long *)our_sys_openat) { + pr_alert("发现系统调用被其他人修改"); + pr_alert("系统可能处于不稳定状态"); + } + + disable_write_protection(); + sys_call_table_stolen[__NR_openat] = (unsigned long *)original_call; + enable_write_protection(); +#endif + + msleep(2000); +} + +module_init(syscall_steal_start); +module_exit(syscall_steal_end); + +MODULE_LICENSE("GPL"); diff --git a/示例/5-阻塞进程和线程/Makefile b/示例/5-阻塞进程和线程/Makefile new file mode 100644 index 0000000..3573845 --- /dev/null +++ b/示例/5-阻塞进程和线程/Makefile @@ -0,0 +1,13 @@ +obj-m += sleep.o +obj-m += completions.o + + +PWD := $(CURDIR) + +all: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules + gcc cat_nonblock.c -o 查看文件 + +clean: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean + rm 查看文件 diff --git a/示例/5-阻塞进程和线程/cat_nonblock.c b/示例/5-阻塞进程和线程/cat_nonblock.c new file mode 100644 index 0000000..c73f2c2 --- /dev/null +++ b/示例/5-阻塞进程和线程/cat_nonblock.c @@ -0,0 +1,59 @@ +/* + * cat_nonblock.c - 打开一个文件并显示其内容，但不等待输入而是直接退出。 + */ +#include /* 用于 errno */ +#include /* 用于 open */ +#include /* 标准 I/O */ +#include /* 用于 exit */ +#include /* 用于 read */ + +#define MAX_BYTES 1024 * 4 /* 最大读取字节数 */ + +int main(int argc, char *argv[]) +{ + int fd; /* 要读取的文件的文件描述符 */ + size_t bytes; /* 读取的字节数 */ + char buffer[MAX_BYTES]; /* 存储读取字节的缓冲区 */ + + /* 用法说明 */ + if (argc != 2) { + printf("用法: %s <文件名>\n", argv[0]); + puts("读取文件的内容，但不等待输入"); + exit(-1); + } + + /* 以非阻塞模式打开文件 */ + fd = open(argv[1], O_RDONLY | O_NONBLOCK); + + /* 如果打开失败 */ + if (fd == -1) { + puts(errno == EAGAIN ? "打开会阻塞" : "打开失败"); + exit(-1); + } + + /* 读取文件并输出其内容 */ + do { + /* 从文件中读取字符 */ + bytes = read(fd, buffer, MAX_BYTES); + + /* 如果发生错误，报告错误并退出 */ + if (bytes == -1) { + if (errno == EAGAIN) + puts("正常情况下会阻塞，但你告诉我不阻塞"); + else + puts("读取错误"); + exit(-1); + } + + /* 打印读取的字符 */ + if (bytes > 0) { + for (int i = 0; i < bytes; i++) + putchar(buffer[i]); + } + + /* 当没有错误且文件未结束时继续 */ + } while (bytes > 0); + + return 0; +} + diff --git a/示例/5-阻塞进程和线程/completions.c b/示例/5-阻塞进程和线程/completions.c new file mode 100644 index 0000000..eb6e32d --- /dev/null +++ b/示例/5-阻塞进程和线程/completions.c @@ -0,0 +1,89 @@ +/* + * completions.c 完成情况示例程序 + */ +#include +#include /* 引入 IS_ERR() */ +#include +#include +#include +#include +#include + +static struct completion crank_comp; /* 定义完成情况 crank_comp */ +static struct completion flywheel_comp; /* 定义完成情况 flywheel_comp */ + +/* crank线程函数 */ +static int machine_crank_thread(void *arg) +{ + pr_info("crank转动\n"); + + complete_all(&crank_comp); /* 设置 crank_comp 完成情况 */ + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 17, 0) + kthread_complete_and_exit(&crank_comp, 0); /* 内核版本 >= 5.17，使用 kthread 完成并退出 */ +#else + complete_and_exit(&crank_comp, 0); /* 否则，使用旧版本接口完成并退出 */ +#endif +} + +/* flywheel启动线程函数 */ +static int machine_flywheel_spinup_thread(void *arg) +{ + wait_for_completion(&crank_comp); /* 等待 crank_comp 完成情况 */ + + pr_info("flywheel启动\n"); + + complete_all(&flywheel_comp); /* 设置 flywheel_comp 完成情况 */ + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 17, 0) + kthread_complete_and_exit(&flywheel_comp, 0); /* 内核版本 >= 5.17，使用 kthread 完成并退出 */ +#else + complete_and_exit(&flywheel_comp, 0); /* 否则，使用旧版本接口完成并退出 */ +#endif +} + +static int __init completions_init(void) +{ + struct task_struct *crank_thread; /* crank线程 */ + struct task_struct *flywheel_thread; /* flywheel线程 */ + + pr_info("完成情况示例加载\n"); + + init_completion(&crank_comp); /* 初始化 crank_comp 完成情况 */ + init_completion(&flywheel_comp); /* 初始化 flywheel_comp 完成情况 */ + + crank_thread = kthread_create(machine_crank_thread, NULL, "KThread Crank"); /* 创建crank线程 */ + if (IS_ERR(crank_thread)) + goto ERROR_THREAD_1; + + flywheel_thread = kthread_create(machine_flywheel_spinup_thread, NULL, + "KThread Flywheel"); /* 创建flywheel线程 */ + if (IS_ERR(flywheel_thread)) + goto ERROR_THREAD_2; + + wake_up_process(flywheel_thread); /* 启动flywheel线程 */ + wake_up_process(crank_thread); /* 启动crank线程 */ + + return 0; + +ERROR_THREAD_2: + kthread_stop(crank_thread); /* 停止crank线程 */ +ERROR_THREAD_1: + + return -1; +} + +static void __exit completions_exit(void) +{ + wait_for_completion(&crank_comp); /* 等待crank线程完成 */ + wait_for_completion(&flywheel_comp); /* 等待flywheel线程完成 */ + + pr_info("完成情况示例卸载\n"); +} + +module_init(completions_init); +module_exit(completions_exit); + +MODULE_DESCRIPTION("完成情况示例"); +MODULE_LICENSE("GPL"); + diff --git a/示例/5-阻塞进程和线程/sleep.c b/示例/5-阻塞进程和线程/sleep.c new file mode 100644 index 0000000..28240ba --- /dev/null +++ b/示例/5-阻塞进程和线程/sleep.c @@ -0,0 +1,191 @@ +/* + * sleep.c - 创建一个 /proc 文件, 如果多个进程同时尝试打开该文件, 则除一个进程外, 其他进程都进入休眠状态 + */ + +#include +#include +#include /* 引入 sprintf() */ +#include +#include +#include +#include +#include /* 引入 get_user 和 put_user */ +#include +#include /* 用于让程序休眠和唤醒 */ + +#include +#include + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0) +#define HAVE_PROC_OPS +#endif + +/* 在这里我们保存最后接收到的消息, 以证明我们可以处理输入 */ +#define MESSAGE_LENGTH 80 +static char message[MESSAGE_LENGTH]; + +static struct proc_dir_entry *our_proc_file; +#define PROC_ENTRY_FILENAME "sleep" + +/* 从文件"读取": 由于使用的是 file_operations (内核中定义文件操作的结构体), + * 其中不能使用procfs函数, 因此需要使用标准的文件操作函数(sprintf)来实现输出 + */ +static ssize_t module_output(struct file *file, /* 参见 include/linux/fs.h */ + char __user *buf, /* 将数据放入的缓冲区(在用户段) */ + size_t len, /* 缓冲区的长度 */ + loff_t *offset) +{ + static int finished = 0; + int i; + char output_msg[MESSAGE_LENGTH + 30]; + + /* 返回 0 表示文件结束 */ + if (finished) { + finished = 0; + return 0; + } + + sprintf(output_msg, "最后输入:%s\n", message); + for (i = 0; i < len && output_msg[i]; i++) + put_user(output_msg[i], buf + i); + + finished = 1; + return i; /* 返回"读取"的字节数 */ +} + +/* 当用户向 /proc 文件写入时，此函数接收输入 */ +static ssize_t module_input(struct file *file, /* 文件本身 */ + const char __user *buf, /* 输入缓冲区 */ + size_t length, /* 缓冲区的长度 */ + loff_t *offset) /* 文件的偏移 - 忽略 */ +{ + int i; + /* 将输入放入 Message 中，以便 module_output 可以在后面使用它 */ + for (i = 0; i < MESSAGE_LENGTH - 1 && i < length; i++) + get_user(message[i], buf + i); + /* 标准的、以零终止的字符串 */ + message[i] = '\0'; + + /* 返回使用的输入字符数 */ + return i; +} + +/* 如果文件当前被某人打开，则为 1 */ +static atomic_t already_open = ATOMIC_INIT(0); + +/* 等待我们文件的进程队列 */ +static DECLARE_WAIT_QUEUE_HEAD(waitq); + +/* 当 /proc 文件被打开时调用 */ +static int module_open(struct inode *inode, struct file *file) +{ + /* 尝试在不阻塞的情况下获取 */ + if (!atomic_cmpxchg(&already_open, 0, 1)) { + /* 在不阻塞的情况下成功，允许访问 */ + try_module_get(THIS_MODULE); + return 0; + } + /* 如果文件标志包含 O_NONBLOCK，意味着进程不希望等待文件。在这种情况下，因为文件已经被打开， + * 我们应该返回 -EAGAIN，表示“你必须再试一次”，而不是阻塞一个更愿意保持清醒的进程。 + */ + if (file->f_flags & O_NONBLOCK) + return -EAGAIN; + + /* 这是调用 try_module_get(THIS_MODULE) 的正确位置，因为如果进程在模块内部的循环中，内核模块不能被移除 */ + try_module_get(THIS_MODULE); + + while (atomic_cmpxchg(&already_open, 0, 1)) { + int i, is_sig = 0; + pr_info("阻塞等待中\n"); + /* 这个函数会将当前进程(包括任何系统调用)挂起, 并在函数调用wake_up(&waitq)后恢复 + * 向进程发送退出信号也可以使其恢复信号(例如 ctrl-c)。 + */ + wait_event_interruptible(waitq, !atomic_read(&already_open)); + + /* 判断当前进程是否有待处理的非阻塞信号(主要用于在等待途中随时可以被中断) */ + for (i = 0; i < _NSIG_WORDS && !is_sig; i++) + is_sig = current->pending.signal.sig[i] & ~current->blocked.sig[i]; + + if (is_sig) { + /* 对于那些被中断的打开操作，不会自动关闭。不在这里减少计数器，后续程序就无法按照预期将计数器降到零， + * 这将导致我们有一个永不消失的模块，只能通过重启机器来清除。 + */ + pr_info("已被中断, 退出完成\n"); + module_put(THIS_MODULE); + return -EINTR; + } + } + return 0; /* 允许访问 */ +} + +/* 当 /proc 文件被关闭时调用 */ +static int module_close(struct inode *inode, struct file *file) +{ + /* 将 already_open 设置为零，以便 waitq 中的一个进程可以将 already_open 设置回1，并打开文件。 + * 所有进程将在 already_open 变回1时被唤醒，所以它们将重新进入睡眠状态 + */ + atomic_set(&already_open, 0); + + /* 唤醒 waitq 中的所有进程，如果有人在等待文件，他们可以获得它 */ + wake_up(&waitq); + + module_put(THIS_MODULE); + + return 0; /* 成功 */ +} + +/* 注册为 /proc 文件的结构，包含指向所有相关函数的指针 */ + +/* 我们的 proc 文件的文件操作。这是我们放置所有处理对文件进行操作 + * 时调用的函数指针的地方。NULL表示我们不想处理某些操作。 + */ +#ifdef HAVE_PROC_OPS +static const struct proc_ops file_ops_4_our_proc_file = { + .proc_read = module_output, /* 从文件"读取" */ + .proc_write = module_input, /* 向文件"写入" */ + .proc_open = module_open, /* 当 /proc 文件被打开时调用 */ + .proc_release = module_close, /* 当文件关闭时调用 */ + .proc_lseek = noop_llseek, /* 返回 file->f_pos */ +}; +#else +static const struct file_operations file_ops_4_our_proc_file = { + .read = module_output, + .write = module_input, + .open = module_open, + .release = module_close, + .llseek = noop_llseek, +}; +#endif + +/* 初始化模块 - 注册 proc 文件 */ +static int __init sleep_init(void) +{ + our_proc_file = + proc_create(PROC_ENTRY_FILENAME, 0644, NULL, &file_ops_4_our_proc_file); + if (our_proc_file == NULL) { + pr_debug("错误: 无法初始化 /proc/%s\n", PROC_ENTRY_FILENAME); + return -ENOMEM; + } + proc_set_size(our_proc_file, 80); + proc_set_user(our_proc_file, GLOBAL_ROOT_UID, GLOBAL_ROOT_GID); + + pr_info("/proc/%s 已创建\n", PROC_ENTRY_FILENAME); + + return 0; +} + +/* 清理 - 从 /proc 注销我们的文件。如果在 waitq 中仍有进程等待， + * 这可能会变得危险，因为它们在我们的打开函数中，而这个函数将被卸载。 + * 我会在第十章中解释如何避免在这种情况下移除内核模块。 + */ +static void __exit sleep_exit(void) +{ + remove_proc_entry(PROC_ENTRY_FILENAME, NULL); + pr_debug("/proc/%s 已移除\n", PROC_ENTRY_FILENAME); +} + +module_init(sleep_init); +module_exit(sleep_exit); + +MODULE_LICENSE("GPL"); + diff --git a/示例/6-内核模块的锁/Makefile b/示例/6-内核模块的锁/Makefile new file mode 100644 index 0000000..0d3f3ed --- /dev/null +++ b/示例/6-内核模块的锁/Makefile @@ -0,0 +1,14 @@ +obj-m += example_mutex.o +obj-m += example_spinlock.o +obj-m += example_rwlock.o +obj-m += example_atomic.o + + +PWD := $(CURDIR) + +all: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules + +clean: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean + diff --git a/示例/6-内核模块的锁/example_atomic.c b/示例/6-内核模块的锁/example_atomic.c new file mode 100644 index 0000000..698ab12 --- /dev/null +++ b/示例/6-内核模块的锁/example_atomic.c @@ -0,0 +1,76 @@ +/* + * example_atomic.c + */ +#include +#include +#include +#include + +#define BYTE_TO_BINARY_PATTERN "%c%c%c%c%c%c%c%c" +#define BYTE_TO_BINARY(byte) \ + ((byte & 0x80) ? '1' : '0'), ((byte & 0x40) ? '1' : '0'), \ + ((byte & 0x20) ? '1' : '0'), ((byte & 0x10) ? '1' : '0'), \ + ((byte & 0x08) ? '1' : '0'), ((byte & 0x04) ? '1' : '0'), \ + ((byte & 0x02) ? '1' : '0'), ((byte & 0x01) ? '1' : '0') + +/* 演示原子加法和减法操作 */ +static void atomic_add_subtract(void) +{ + atomic_t rimian; + atomic_t xunmi = ATOMIC_INIT(50); + /* 赋值为45 */ + atomic_set(&rimian, 45); + /* 减去1(45-1=44) */ + atomic_dec(&rimian); + /* 加上7(44+7=51) */ + atomic_add(7, &rimian); + /* 加1(51+1=52) */ + atomic_inc(&rimian); + /* 两个名字, 没有其他意义 */ + pr_info("寻觅: %d, 日冕: %d\n", atomic_read(&xunmi), + atomic_read(&rimian)); +} + +/* 演示原子位操作 */ +static void atomic_bitwise(void) +{ + unsigned long word = 0; + + pr_info("初始 0: " BYTE_TO_BINARY_PATTERN, BYTE_TO_BINARY(word)); + set_bit(3, &word); // 设置第3位为1 + set_bit(5, &word); // 设置第5位为1 + pr_info("修正 1: " BYTE_TO_BINARY_PATTERN, BYTE_TO_BINARY(word)); + clear_bit(5, &word); // 清除第5位 + pr_info("修正 2: " BYTE_TO_BINARY_PATTERN, BYTE_TO_BINARY(word)); + change_bit(3, &word); // 切换第3位的值 + pr_info("修正 3: " BYTE_TO_BINARY_PATTERN, BYTE_TO_BINARY(word)); + + // 检查第3位，如果原本为1，则返回 `非预期值` 的输出, 如果不是1则将其设置为1 + if (test_and_set_bit(3, &word)) + pr_info("非预期值\n"); + pr_info("修正 4: " BYTE_TO_BINARY_PATTERN, BYTE_TO_BINARY(word)); + + word = 255; // 设置word的所有位为1 + pr_info("修正 5: " BYTE_TO_BINARY_PATTERN "\n", BYTE_TO_BINARY(word)); +} + +static int __init example_atomic_init(void) +{ + pr_info("原子操作示例开始\n"); + + atomic_add_subtract(); + atomic_bitwise(); + + return 0; +} + +static void __exit example_atomic_exit(void) +{ + pr_info("原子操作示例退出\n"); +} + +module_init(example_atomic_init); +module_exit(example_atomic_exit); + +MODULE_DESCRIPTION("原子操作示例"); +MODULE_LICENSE("GPL"); diff --git a/示例/6-内核模块的锁/example_mutex.c b/示例/6-内核模块的锁/example_mutex.c new file mode 100644 index 0000000..25d0fb0 --- /dev/null +++ b/示例/6-内核模块的锁/example_mutex.c @@ -0,0 +1,40 @@ +/* + * example_mutex.c + */ +#include +#include +#include + +static DEFINE_MUTEX(mymutex); + +static int __init example_mutex_init(void) +{ + int ret; + + pr_info("example_mutex 初始化\n"); + + ret = mutex_trylock(&mymutex); + if (ret != 0) { + pr_info("已锁定\n"); + + if (mutex_is_locked(&mymutex) == 0) + pr_info("锁定失败!\n"); + + mutex_unlock(&mymutex); + pr_info("已解锁\n"); + } else + pr_info("锁定失败\n"); + + return 0; +} + +static void __exit example_mutex_exit(void) +{ + pr_info("example_mutex 卸载\n"); +} + +module_init(example_mutex_init); +module_exit(example_mutex_exit); + +MODULE_DESCRIPTION("互斥锁示例"); +MODULE_LICENSE("GPL"); diff --git a/示例/6-内核模块的锁/example_rwlock.c b/示例/6-内核模块的锁/example_rwlock.c new file mode 100644 index 0000000..4ddf36e --- /dev/null +++ b/示例/6-内核模块的锁/example_rwlock.c @@ -0,0 +1,55 @@ +/* + * example_rwlock.c + */ +#include +#include +#include + +static DEFINE_RWLOCK(myrwlock); + +static void example_read_lock(void) +{ + unsigned long flags; + + read_lock_irqsave(&myrwlock, flags); + pr_info("读锁已加锁\n"); + + /* 从某处读取数据 */ + + read_unlock_irqrestore(&myrwlock, flags); + pr_info("读锁已解锁\n"); +} + +static void example_write_lock(void) +{ + unsigned long flags; + + write_lock_irqsave(&myrwlock, flags); + pr_info("写锁已加锁\n"); + + /* 向某处写入数据 */ + + write_unlock_irqrestore(&myrwlock, flags); + pr_info("写锁已解锁\n"); +} + +static int __init example_rwlock_init(void) +{ + pr_info("example_rwlock 模块启动\n"); + + example_read_lock(); + example_write_lock(); + + return 0; +} + +static void __exit example_rwlock_exit(void) +{ + pr_info("example_rwlock 模块退出\n"); +} + +module_init(example_rwlock_init); +module_exit(example_rwlock_exit); + +MODULE_DESCRIPTION("读/写锁示例"); +MODULE_LICENSE("GPL"); diff --git a/示例/6-内核模块的锁/example_spinlock.c b/示例/6-内核模块的锁/example_spinlock.c new file mode 100644 index 0000000..6fde427 --- /dev/null +++ b/示例/6-内核模块的锁/example_spinlock.c @@ -0,0 +1,62 @@ +/* + * example_spinlock.c + */ +#include +#include +#include +#include + +static DEFINE_SPINLOCK(sl_static); +static spinlock_t sl_dynamic; + +static void example_spinlock_static(void) +{ + unsigned long flags; + + spin_lock_irqsave(&sl_static, flags); + pr_info("已锁定静态自旋锁\n"); + + /* 执行一些安全的操作。由于这会占用 100% 的 CPU 时间， + * 这段代码应该运行时间不超过几毫秒。 + */ + + spin_unlock_irqrestore(&sl_static, flags); + pr_info("已解锁静态自旋锁\n"); +} + +static void example_spinlock_dynamic(void) +{ + unsigned long flags; + + spin_lock_init(&sl_dynamic); + spin_lock_irqsave(&sl_dynamic, flags); + pr_info("已锁定动态自旋锁\n"); + + /* 执行一些安全的操作。由于这会占用 100% 的 CPU 时间， + * 这段代码应该运行时间不超过几毫秒。 + */ + + spin_unlock_irqrestore(&sl_dynamic, flags); + pr_info("已解锁动态自旋锁\n"); +} + +static int __init example_spinlock_init(void) +{ + pr_info("自旋锁示例启动\n"); + + example_spinlock_static(); + example_spinlock_dynamic(); + + return 0; +} + +static void __exit example_spinlock_exit(void) +{ + pr_info("自旋锁示例退出\n"); +} + +module_init(example_spinlock_init); +module_exit(example_spinlock_exit); + +MODULE_DESCRIPTION("自旋锁示例"); +MODULE_LICENSE("GPL"); diff --git a/示例/7-驱动与用户交互/Makefile b/示例/7-驱动与用户交互/Makefile new file mode 100644 index 0000000..a2cc20b --- /dev/null +++ b/示例/7-驱动与用户交互/Makefile @@ -0,0 +1,12 @@ +obj-m += print_string.o +obj-m += kbleds.o + + +PWD := $(CURDIR) + +all: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules + +clean: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean + diff --git a/示例/7-驱动与用户交互/kbleds.c b/示例/7-驱动与用户交互/kbleds.c new file mode 100644 index 0000000..d128238 --- /dev/null +++ b/示例/7-驱动与用户交互/kbleds.c @@ -0,0 +1,81 @@ +/* + * kbleds.c - 闪烁键盘LED直到模块被卸载。 + */ + +#include +#include /* 引入 KDSETLED */ +#include +#include /* 引入 tty_struct */ +#include /* 引入 MAX_NR_CONSOLES */ +#include /* 引入 fg_console */ +#include /* 引入 vc_cons */ + +MODULE_DESCRIPTION("示例模块，演示如何使用键盘LED。"); + +static struct timer_list my_timer; +static struct tty_driver *my_driver; +static unsigned long kbledstatus = 0; + +#define BLINK_DELAY HZ / 5 +#define ALL_LEDS_ON 0x07 +#define RESTORE_LEDS 0xFF + +/* 函数 my_timer_func 定期闪烁键盘LED，通过在键盘驱动上调用 ioctl() 命令 KDSETLED 实现。 + * 要了解更多关于虚拟终端 ioctl 操作的信息，请参见文件：drivers/tty/vt/vt_ioctl.c, 函数 vt_ioctl() + * + * KDSETLED 的参数交替设置为 7（从而使 LED 模式设置为 LED_SHOW_IOCTL，所有的 LED 都被点亮）和 0xFF + * （任何大于 7 的值会将 LED 模式切换回 LED_SHOW_FLAGS，因此 LED 反映实际的键盘状态）。要了解更多信息， + * 请参见文件：drivers/tty/vt/keyboard.c, 函数 setledstate()。 + */ +static void my_timer_func(struct timer_list *unused) +{ + struct tty_struct *t = vc_cons[fg_console].d->port.tty; + + if (kbledstatus == ALL_LEDS_ON) + kbledstatus = RESTORE_LEDS; + else + kbledstatus = ALL_LEDS_ON; + + (my_driver->ops->ioctl)(t, KDSETLED, kbledstatus); + + my_timer.expires = jiffies + BLINK_DELAY; + add_timer(&my_timer); +} + +static int __init kbleds_init(void) +{ + int i; + + pr_info("kbleds: 正在加载\n"); + pr_info("kbleds: 前台控制台为 %x\n", fg_console); + for (i = 0; i < MAX_NR_CONSOLES; i++) { + if (!vc_cons[i].d) + break; + pr_info("poet_atkm: 控制台[%i/%i] #%i, tty %p\n", i, MAX_NR_CONSOLES, + vc_cons[i].d->vc_num, (void *)vc_cons[i].d->port.tty); + } + pr_info("kbleds: 扫描控制台完成\n"); + + my_driver = vc_cons[fg_console].d->port.tty->driver; + pr_info("kbleds: tty 驱动程序名称 %s\n", my_driver->driver_name); + + /* 设置 LED 闪烁定时器。 */ + timer_setup(&my_timer, my_timer_func, 0); + my_timer.expires = jiffies + BLINK_DELAY; + add_timer(&my_timer); + + return 0; +} + +static void __exit kbleds_cleanup(void) +{ + pr_info("kbleds: 正在卸载...\n"); + del_timer(&my_timer); + (my_driver->ops->ioctl)(vc_cons[fg_console].d->port.tty, KDSETLED, + RESTORE_LEDS); +} + +module_init(kbleds_init); +module_exit(kbleds_cleanup); + +MODULE_LICENSE("GPL"); diff --git a/示例/7-驱动与用户交互/print_string.c b/示例/7-驱动与用户交互/print_string.c new file mode 100644 index 0000000..ec58251 --- /dev/null +++ b/示例/7-驱动与用户交互/print_string.c @@ -0,0 +1,59 @@ +/* + * print_string.c - 将输出发送到我们运行的tty，无论是通过X11、telnet等。我们通过将字符串打印到当前任务关联的tty + */ +#include +#include +#include +#include /* 引入 current */ +#include /* 引入 tty 相关声明 */ + +static void print_string(char *str) +{ + /* 当前任务的tty */ + struct tty_struct *my_tty = get_current_tty(); + + /* 如果my_tty为NULL，则当前任务没有可以打印的tty(例如，如果它是一个守护进程)。如果是这样，我们无法执行任何操作 */ + if (my_tty) { + const struct tty_operations *ttyops = my_tty->driver->ops; + /* my_tty->driver是一个包含tty函数的结构体，其中一个函数（write）用于将字符串写入tty。 + * 它可以用于从用户或内核的内存段获取字符串。 + * + * 该函数的第一个参数是要写入的tty，因为同样的函数通常会用于所有相同类型的tty。 + * 第二个参数是指向字符串的指针。第三个参数是字符串的长度。 + * + * 如下所示，有时需要使用预处理器来创建适用于不同内核版本的代码。我们在这里采取的方法不具备通用性 + * 处理这种情况的正确方法在linux/Documentation/SubmittingPatches的第2节中有描述。 + */ + (ttyops->write)(my_tty, /* tty本身 */ + str, /* 字符串 */ + strlen(str)); /* 长度 */ + + /* tty最初是硬件设备，通常严格遵循ASCII标准。在ASCII中，要换行需要两个字符，即回车符(结束当前行)和换行符(开始新行)。 + * 在Unix中，ASCII换行符用于两个目的 - 因此我们不能只使用\n，因为它没有回车符，下行会在换行符后的列开始。 + * + * Unix 和 MS Windows 的文本文件格式因而有所不同 + * - Unix 文本文件使用单一的 LF（\n），在显示或编辑时会在每个 LF 位置换行。 + * - Windows 文本文件使用 CR+LF（\r\n），在显示或编辑时会在每个 CR+LF 位置换行。 + * + * \015 代表 Carriage Return (CR)，即 ASCII 值为 13 + * \012 代表 Line Feed (LF)，即 ASCII 值为 10 + */ + (ttyops->write)(my_tty, "\015\012", 2); + } +} + +static int __init print_string_init(void) +{ + print_string("模块已插入。你好, 世界! "); + return 0; +} + +static void __exit print_string_exit(void) +{ + print_string("模块已移除。再见, 世界! "); +} + +module_init(print_string_init); +module_exit(print_string_exit); + +MODULE_LICENSE("GPL"); diff --git a/示例/8-调度与中断/Makefile b/示例/8-调度与中断/Makefile new file mode 100644 index 0000000..c6fd30d --- /dev/null +++ b/示例/8-调度与中断/Makefile @@ -0,0 +1,14 @@ +obj-m += example_tasklet.o +obj-m += sched.o +obj-m += intrpt.o +obj-m += intrpt_old.o + + +PWD := $(CURDIR) + +all: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules + +clean: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean + diff --git a/示例/8-调度与中断/example_tasklet.c b/示例/8-调度与中断/example_tasklet.c new file mode 100644 index 0000000..b58675f --- /dev/null +++ b/示例/8-调度与中断/example_tasklet.c @@ -0,0 +1,47 @@ +/* + * example_tasklet.c + */ +#include +#include +#include +#include + +/* 宏 DECLARE_TASKLET_OLD 存在是为了兼容性 参见 https://lwn.net/Articles/830964/ */ +#ifndef DECLARE_TASKLET_OLD +#define DECLARE_TASKLET_OLD(arg1, arg2) DECLARE_TASKLET(arg1, arg2, 0L) +#endif + +/* tasklet_fn 是 tasklet 执行的函数，接收一个 unsigned long 类型的参数 */ +static void tasklet_fn(unsigned long data) +{ + pr_info("示例 tasklet 开始执行!\n"); + mdelay(20000); // 延迟 10 秒 + pr_info("示例 tasklet 执行结束!\n"); +} + +/* 定义一个 tasklet，并将 tasklet_fn 作为其处理函数 */ +static DECLARE_TASKLET_OLD(mytask, tasklet_fn); + +/* 模块初始化函数 */ +static int __init example_tasklet_init(void) +{ + pr_info("tasklet 示例初始化\n"); + tasklet_schedule(&mytask); // 安排 tasklet 执行 + mdelay(10); + pr_info("示例 tasklet 初始化继续...\n"); + return 0; +} + +/* 模块退出函数 */ +static void __exit example_tasklet_exit(void) +{ + pr_info("tasklet 示例退出\n"); + tasklet_kill(&mytask); // 终止 tasklet 的执行 +} + +module_init(example_tasklet_init); +module_exit(example_tasklet_exit); + +MODULE_DESCRIPTION("Tasklet 示例"); +MODULE_LICENSE("GPL"); + diff --git a/示例/8-调度与中断/intrpt.c b/示例/8-调度与中断/intrpt.c new file mode 100644 index 0000000..7602c86 --- /dev/null +++ b/示例/8-调度与中断/intrpt.c @@ -0,0 +1,151 @@ +/* + * intrpt.c - 处理带中断的 GPIO + * + * 基于 Stefan Wendler (devnull@kaltpost.de) 提供的 RPi 示例： + * https://github.com/wendlers/rpi-kmod-samples + * + * 按下一个按钮点亮 LED，按下另一个按钮熄灭 LED。 + */ + +#include +#include +#include /* 用于 ARRAY_SIZE() */ +#include +#include + +static int button_irqs[] = { -1, -1 }; + +/* 定义 LED 的 GPIO。 + * TODO: 根据你的板子更改 GPIO 编号。 + */ +static struct gpio leds[] = { { 1, GPIOF_OUT_INIT_LOW, "LED 1" } }; + +/* 定义按钮的 GPIO。 + * TODO: 根据你的板子更改 GPIO 编号。 + */ +static struct gpio buttons[] = { { 2, GPIOF_IN, "LED 1 打开按钮" }, + { 3, GPIOF_IN, "LED 1 关闭按钮" } }; + +/* 按钮按下时触发的中断函数。 */ +static irqreturn_t button_isr(int irq, void *data) +{ + /* 第一个按钮 */ + if (irq == button_irqs[0] && !gpio_get_value(leds[0].gpio)) + gpio_set_value(leds[0].gpio, 1); /* 点亮 LED */ + /* 第二个按钮 */ + else if (irq == button_irqs[1] && gpio_get_value(leds[0].gpio)) + gpio_set_value(leds[0].gpio, 0); /* 熄灭 LED */ + + return IRQ_HANDLED; +} + +static int __init intrpt_init(void) +{ + int ret = 0; + + pr_info("%s\n", __func__); + + /* 注册 LED GPIO */ + ret = gpio_request_array(leds, ARRAY_SIZE(leds)); + + if (ret) { + pr_err("无法请求 LED 的 GPIO: %d\n", ret); + return ret; + } + + /* 注册按钮 GPIO */ + ret = gpio_request_array(buttons, ARRAY_SIZE(buttons)); + + if (ret) { + pr_err("无法请求按钮的 GPIO: %d\n", ret); + goto fail1; + } + + pr_info("当前按钮1的值: %d\n", gpio_get_value(buttons[0].gpio)); + + ret = gpio_to_irq(buttons[0].gpio); + + if (ret < 0) { + pr_err("无法请求 IRQ: %d\n", ret); + goto fail2; + } + + button_irqs[0] = ret; + + pr_info("成功请求 BUTTON1 的 IRQ # %d\n", button_irqs[0]); + + /* 请求按钮1的中断 + * IRQF_TRIGGER_RISING 表示在信号电平从低到高变化时触发中断 + * IRQF_TRIGGER_FALLING 表示在信号电平从高到低变化时触发中断 + * 这种组合使得中断处理函数在检测到按钮的按下和释放时都会被调用。 + * */ + ret = request_irq(button_irqs[0], button_isr, + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, + "gpio模块#按钮1", NULL); + + if (ret) { + pr_err("无法请求 IRQ: %d\n", ret); + goto fail2; + } + + ret = gpio_to_irq(buttons[1].gpio); + + if (ret < 0) { + pr_err("无法请求 IRQ: %d\n", ret); + goto fail2; + } + + button_irqs[1] = ret; + + pr_info("成功请求 BUTTON2 的 IRQ # %d\n", button_irqs[1]); + + /* 请求按钮2的中断, 标志位同上 */ + ret = request_irq(button_irqs[1], button_isr, + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, + "gpio模块#按钮2", NULL); + + if (ret) { + pr_err("无法请求 IRQ: %d\n", ret); + goto fail3; + } + + return 0; + +/* 清理已经设置的部分 */ +fail3: + free_irq(button_irqs[0], NULL); /* 释放按钮1的中断请求 */ + +fail2: + gpio_free_array(buttons, ARRAY_SIZE(buttons)); /* 释放按钮的GPIO */ + +fail1: + gpio_free_array(leds, ARRAY_SIZE(leds)); /* 释放LED的GPIO */ + + return ret; +} + +static void __exit intrpt_exit(void) +{ + int i; + + pr_info("%s\n", __func__); + + /* 释放 IRQ */ + free_irq(button_irqs[0], NULL); + free_irq(button_irqs[1], NULL); + + /* 关闭所有 LED */ + for (i = 0; i < ARRAY_SIZE(leds); i++) + gpio_set_value(leds[i].gpio, 0); + + /* 注销 GPIO */ + gpio_free_array(leds, ARRAY_SIZE(leds)); + gpio_free_array(buttons, ARRAY_SIZE(buttons)); +} + +module_init(intrpt_init); +module_exit(intrpt_exit); + +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("处理一些 GPIO 中断"); + diff --git a/示例/8-调度与中断/sched.c b/示例/8-调度与中断/sched.c new file mode 100644 index 0000000..7eeb0b3 --- /dev/null +++ b/示例/8-调度与中断/sched.c @@ -0,0 +1,34 @@ +/* + * sched.c + */ +#include +#include +#include + +static struct workqueue_struct *queue = NULL; +static struct work_struct work; + +static void work_handler(struct work_struct *data) +{ + pr_info("工作队列函数\n"); +} + +static int __init sched_init(void) +{ + queue = alloc_workqueue("HELLOWORLD", WQ_UNBOUND, 1); + INIT_WORK(&work, work_handler); + queue_work(queue, &work); + return 0; +} + +static void __exit sched_exit(void) +{ + destroy_workqueue(queue); +} + +module_init(sched_init); +module_exit(sched_exit); + +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("工作队列示例"); + diff --git a/示例/Makefile b/示例/Makefile new file mode 100644 index 0000000..483bc09 --- /dev/null +++ b/示例/Makefile @@ -0,0 +1,11 @@ +obj-m += example_taskle.o + + +PWD := $(CURDIR) + +all: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules + +clean: + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean + diff --git a/examples/.clang-format b/示例/原始示例/.clang-format similarity index 100% rename from examples/.clang-format rename to 示例/原始示例/.clang-format diff --git a/examples/Makefile b/示例/原始示例/Makefile similarity index 100% rename from examples/Makefile rename to 示例/原始示例/Makefile diff --git a/examples/bh_threaded.c b/示例/原始示例/bh_threaded.c similarity index 100% rename from examples/bh_threaded.c rename to 示例/原始示例/bh_threaded.c diff --git a/examples/bottomhalf.c b/示例/原始示例/bottomhalf.c similarity index 100% rename from examples/bottomhalf.c rename to 示例/原始示例/bottomhalf.c diff --git a/examples/chardev.c b/示例/原始示例/chardev.c similarity index 100% rename from examples/chardev.c rename to 示例/原始示例/chardev.c diff --git a/examples/chardev.h b/示例/原始示例/chardev.h similarity index 100% rename from examples/chardev.h rename to 示例/原始示例/chardev.h diff --git a/examples/chardev2.c b/示例/原始示例/chardev2.c similarity index 100% rename from examples/chardev2.c rename to 示例/原始示例/chardev2.c diff --git a/examples/completions.c b/示例/原始示例/completions.c similarity index 100% rename from examples/completions.c rename to 示例/原始示例/completions.c diff --git a/examples/devicemodel.c b/示例/原始示例/devicemodel.c similarity index 100% rename from examples/devicemodel.c rename to 示例/原始示例/devicemodel.c diff --git a/examples/example_atomic.c b/示例/原始示例/example_atomic.c similarity index 100% rename from examples/example_atomic.c rename to 示例/原始示例/example_atomic.c diff --git a/examples/example_mutex.c b/示例/原始示例/example_mutex.c similarity index 100% rename from examples/example_mutex.c rename to 示例/原始示例/example_mutex.c diff --git a/examples/example_rwlock.c b/示例/原始示例/example_rwlock.c similarity index 100% rename from examples/example_rwlock.c rename to 示例/原始示例/example_rwlock.c diff --git a/examples/example_spinlock.c b/示例/原始示例/example_spinlock.c similarity index 100% rename from examples/example_spinlock.c rename to 示例/原始示例/example_spinlock.c diff --git a/examples/example_tasklet.c b/示例/原始示例/example_tasklet.c similarity index 100% rename from examples/example_tasklet.c rename to 示例/原始示例/example_tasklet.c diff --git a/examples/hello-1.c b/示例/原始示例/hello-1.c similarity index 100% rename from examples/hello-1.c rename to 示例/原始示例/hello-1.c diff --git a/examples/hello-2.c b/示例/原始示例/hello-2.c similarity index 100% rename from examples/hello-2.c rename to 示例/原始示例/hello-2.c diff --git a/examples/hello-3.c b/示例/原始示例/hello-3.c similarity index 100% rename from examples/hello-3.c rename to 示例/原始示例/hello-3.c diff --git a/examples/hello-4.c b/示例/原始示例/hello-4.c similarity index 100% rename from examples/hello-4.c rename to 示例/原始示例/hello-4.c diff --git a/examples/hello-5.c b/示例/原始示例/hello-5.c similarity index 100% rename from examples/hello-5.c rename to 示例/原始示例/hello-5.c diff --git a/examples/hello-sysfs.c b/示例/原始示例/hello-sysfs.c similarity index 100% rename from examples/hello-sysfs.c rename to 示例/原始示例/hello-sysfs.c diff --git a/examples/intrpt.c b/示例/原始示例/intrpt.c similarity index 100% rename from examples/intrpt.c rename to 示例/原始示例/intrpt.c diff --git a/examples/ioctl.c b/示例/原始示例/ioctl.c similarity index 100% rename from examples/ioctl.c rename to 示例/原始示例/ioctl.c diff --git a/examples/kbleds.c b/示例/原始示例/kbleds.c similarity index 100% rename from examples/kbleds.c rename to 示例/原始示例/kbleds.c diff --git a/examples/other/cat_nonblock.c b/示例/原始示例/other/cat_nonblock.c similarity index 100% rename from examples/other/cat_nonblock.c rename to 示例/原始示例/other/cat_nonblock.c diff --git a/examples/other/userspace_ioctl.c b/示例/原始示例/other/userspace_ioctl.c similarity index 100% rename from examples/other/userspace_ioctl.c rename to 示例/原始示例/other/userspace_ioctl.c diff --git a/examples/print_string.c b/示例/原始示例/print_string.c similarity index 100% rename from examples/print_string.c rename to 示例/原始示例/print_string.c diff --git a/examples/procfs1.c b/示例/原始示例/procfs1.c similarity index 100% rename from examples/procfs1.c rename to 示例/原始示例/procfs1.c diff --git a/examples/procfs2.c b/示例/原始示例/procfs2.c similarity index 100% rename from examples/procfs2.c rename to 示例/原始示例/procfs2.c diff --git a/examples/procfs3.c b/示例/原始示例/procfs3.c similarity index 100% rename from examples/procfs3.c rename to 示例/原始示例/procfs3.c diff --git a/examples/procfs4.c b/示例/原始示例/procfs4.c similarity index 100% rename from examples/procfs4.c rename to 示例/原始示例/procfs4.c diff --git a/examples/sched.c b/示例/原始示例/sched.c similarity index 100% rename from examples/sched.c rename to 示例/原始示例/sched.c diff --git a/examples/sleep.c b/示例/原始示例/sleep.c similarity index 100% rename from examples/sleep.c rename to 示例/原始示例/sleep.c diff --git a/examples/start.c b/示例/原始示例/start.c similarity index 100% rename from examples/start.c rename to 示例/原始示例/start.c diff --git a/examples/static_key.c b/示例/原始示例/static_key.c similarity index 100% rename from examples/static_key.c rename to 示例/原始示例/static_key.c diff --git a/examples/stop.c b/示例/原始示例/stop.c similarity index 100% rename from examples/stop.c rename to 示例/原始示例/stop.c diff --git a/examples/syscall-steal.c b/示例/原始示例/syscall-steal.c similarity index 100% rename from examples/syscall-steal.c rename to 示例/原始示例/syscall-steal.c diff --git a/examples/vinput.c b/示例/原始示例/vinput.c similarity index 100% rename from examples/vinput.c rename to 示例/原始示例/vinput.c diff --git a/examples/vinput.h b/示例/原始示例/vinput.h similarity index 100% rename from examples/vinput.h rename to 示例/原始示例/vinput.h diff --git a/examples/vkbd.c b/示例/原始示例/vkbd.c similarity index 100% rename from examples/vkbd.c rename to 示例/原始示例/vkbd.c