xunmi/nhmk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[汉化] 翻译第6章节

Browse Source
This commit is contained in:
寻觅(樊旭东) 2024-08-05 17:31:33 +08:00
parent b03a709553
commit 2155f68a8d
1 changed files with 107 additions and 176 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

283
lkmpg.tex
View File

@ -63,20 +63,20 @@
\section{引言}
\label{sec:引言}
《Linux内核模块编程指南》是一本免费的书；您可以根据 \href{https://opensource.org/licenses/OSL-3.0}{开放软件许可证(Open Software License)} 3.0版的条款复制和/或修改它。
《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)}的规定。总之, 您可以免费复制和分发本书, 也可以赢利。以任何媒介、物理或电子形式复制本书, 无需获得作者的明确许可。
作者鼓励广泛分发本书供个人或商业使用, 前提是上述版权声明保持不变, 并且该方法符合\href{https://opensource.org/licenses/OSL-3.0}{开放软件许可证(Open Software License)}的规定。总之, 你可以免费复制和分发本书, 也可以赢利。以任何媒介、物理或电子形式复制本书, 无需获得作者的明确许可。
本文档的衍生作品和翻译必须置于开放软件许可证下, 并且原始版权声明必须保持不变。如果您为本书贡献了新材料, 则必须为您的修订提供材料和源代码。请直接向文档维护者Jim Huang提供修订和更新<jserv@ccns.ncku.edu.tw>。这将允许合并更新, 并为Linux社区提供一致的修订。
本文档的衍生作品和翻译必须置于开放软件许可证下, 并且原始版权声明必须保持不变。如果你为本书贡献了新材料, 则必须为你的修订提供材料和源代码。请直接向文档维护者Jim Huang提供修订和更新<jserv@ccns.ncku.edu.tw>。这将允许合并更新, 并为Linux社区提供一致的修订。
如果您以商业方式出版或分发本书, 作者和\href{https://tldp.org/}{Linux文档项目(LDP)}将非常感谢您的捐赠、版税和/或印刷本。以这种方式贡献表明你支持自由软件和LDP。如果您有任何问题或意见, 请联系上述地址。
如果你以商业方式出版或分发本书, 作者和\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文档。
《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:致谢}
@ -127,7 +127,7 @@ sudo pacman -S gcc kmod
sudo lsmod
\end{codebash}
模块存储在文件 \verb|/proc/modules| 中, 因此您也可以使用以下命令查看它们:
模块存储在文件 \verb|/proc/modules| 中, 因此你也可以使用以下命令查看它们:
\begin{codebash}
sudo cat /proc/modules
\end{codebash}
@ -157,7 +157,7 @@ sudo lsmod | grep net
\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}的更详细步骤。
如果在启动“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{开始(头部)}
@ -191,11 +191,11 @@ mkdir -p ~/develop/kernel/hello-1
cd ~/develop/kernel/hello-1
\end{codebash}
将下述代码粘贴到您喜爱的编辑器中, 并将其命名为 \verb|hello-1.c|:
将下述代码粘贴到你喜爱的编辑器中, 并将其命名为 \verb|hello-1.c|:
\samplec{examples/hello-1.c}
现在您需要一个 \verb|Makefile| 。如果复制并粘贴此内容, 请将缩进更改为使用 \textit{制表符(tabs)}, 而不是空格。
现在你需要一个 \verb|Makefile| 。如果复制并粘贴此内容, 请将缩进更改为使用 \textit{制表符(tabs)}, 而不是空格。
\begin{code}
obj-m += hello-1.o
@ -209,7 +209,7 @@ 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| 的更多信息。
在 \verb|Makefile| 中, \verb|$(CURDIR)| 可以设置为当前工作目录的绝对路径名(在处理所有 \verb|-C| 选项后, 如果有)。请参阅 \href{https://www.gnu.org/software/make/manual/make.html}{GNU make manual} 中有关 \verb|CURDIR| 的更多信息。
后续直接运行make即可
@ -217,7 +217,7 @@ clean:
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 手册})。您可以通过以下方式查看环境变量的设置：
如果在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
@ -301,7 +301,7 @@ $ sudo make -p | grep PWD
}
\end{enumerate}
如果一切顺利, 您应该会发现您有一个已编译的\verb|hello-1.ko|模块。您可以使用以下命令查找有关它的信息:
如果一切顺利, 你应该会发现你有一个已编译的\verb|hello-1.ko|模块。你可以使用以下命令查找有关它的信息:
\begin{codebash}
modinfo hello-1.ko
\end{codebash}
@ -316,12 +316,12 @@ sudo lsmod | grep hello
sudo insmod hello-1.ko
\end{codebash}
载入模块时中划线(hello-1)将会被替换成下划线(hello_1), 因此当您再次尝试时:
载入模块时中划线(hello-1)将会被替换成下划线(hello_1), 因此当你再次尝试时:
\begin{codebash}
sudo lsmod | grep hello
\end{codebash}
您应该可以看到已加载的模块。可以使用以下命令再次移除它(请注意, 中划线已被下划线替换):
你应该可以看到已加载的模块。可以使用以下命令再次移除它(请注意, 中划线已被下划线替换):
\begin{codebash}
sudo rmmod hello_1
\end{codebash}
@ -332,26 +332,26 @@ Notice that the dash was replaced by an underscore.
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()| 的 "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|<linux/module.h>|。我们只需要为 \cpp|pr_alert()| 日志级别的宏扩展包含\verb|<linux/printk.h>|, 您将在第\ref{sec:printk}节中了解这一点。
最后, 每个内核模块都需要包含\verb|<linux/module.h>|。我们只需要为 \cpp|pr_alert()| 日志级别的宏扩展包含\verb|<linux/printk.h>|, 你将在第\ref{sec:printk}节中了解这一点。
\begin{enumerate}
\item 关于编码风格。
对任何开始内核编程的人来说都不容易被注意到的事情是, 代码中的缩进应该使用\textbf{制表符(tabs)}, 而不是空格。它是内核的编码约定之一。您可能不喜欢它, 但如果您想要向上游提交补丁, 则需要习惯它。并且内核中的注释无论是单行还是多行都习惯使用 /**/ 的方式而非 //
对任何开始内核编程的人来说都不容易被注意到的事情是, 代码中的缩进应该使用\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 手册})。
一开始是 \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之前, 请务必阅读此文件和相关文件。它可能会为您节省大量工作。
有关内核模块的Makefiles的其他详细信息, 请参阅\src{Documentation/kbuild/makefiles.rst}。在开始修改Makefile之前, 请务必阅读此文件和相关文件。它可能会为你节省大量工作。
\begin{quote}
这里是读者的另一个练习。看到\cpp|init_module()|中return语句上方的注释了吗？将返回值更改为负值, 重新编译并再次加载模块。发生了什么？
@ -360,11 +360,11 @@ sudo journalctl --since "1 hour ago" | grep kernel
\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函数, 否则将出现编译错误。下面是该技术的一个示例：
在早期的内核版本中, 你必须使用 \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
@ -389,39 +389,39 @@ clean:
\cpp|__exit| 宏会在将模块内置到内核时也会被省略, 与 \cpp|__init| 类似, 对可加载模块没有影响。考虑到 退出 函数的作用这种做法也是完全合理的。
这些宏在\src{include/linux/init.h}中定义, 用于释放内核内存。当引导内核并看到类似“释放未使用的内核内存：236k已释放”的内容时, 这正是内核正在释放的内容。
这些宏在\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}中定义。
你可以使用几个宏来指示模块的许可证。常见示例有“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|的宏。下面的示例中说明了该宏和几个描述该模块的其他宏。
要引用你正在使用的许可证, 可以使用名为\cpp|MODULE_LICENSE|的宏。下面的示例中说明了该宏和几个描述该模块的其他宏。
\samplec{examples/hello-4.c}
\subsection{将命令行参数传递到模块}
\label{modparam}
模块可以采用命令行参数, 但不能使用您可能习惯的argc/argv。
模块可以采用命令行参数, 但不能使用你可能习惯的argc/argv。
要允许将参数传递给模块, 请声明将采用命令行参数值的变量作为全局变量, 然后使用 \cpp|module_param()| 宏（在\src{include/linux/moduleparam.h}中定义）来设置机制。在运行时, \sh|insmod| 将使用给定的任何命令行参数填充变量, 如 \sh|insmod mymodule.ko myvariable=5| 。为了清楚起见, 变量声明和宏应该放在模块的开头。这块解释的很糟糕, 还是无法理解可以试着查看实例代码。
要允许将参数传递给模块, 请声明将采用命令行参数值的变量作为全局变量, 然后使用 \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()|。
\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|。这里我们展示了两种可能性：
数组也得到了支持, 但与过去相比, 现在的处理方式有所不同。为了跟踪参数数量, 你需要将一个指向计数变量的指针作为第三个参数传递。你也可以选择忽略计数并传递 \cpp|NULL|。这里我们展示了两种可能性:
\begin{code}
int myintarray[2];
@ -432,9 +432,9 @@ int count;
module_param_array(myshortarray, short, &count, 0); /* 将计数器的值传给count */
\end{code}
这种用法的一个好处是可以设置模块变量的默认值, 如端口或 IO 地址。如果变量包含默认值, 则执行自动检测（在其他地方解释）。否则, 保留当前值。这将在后面详细说明。
这种用法的一个好处是可以设置模块变量的默认值, 如端口或 IO 地址。如果变量包含默认值, 则执行自动检测(在其他地方解释)。否则, 保留当前值。这将在后面详细说明。
最后, 有一个宏函数\cpp|MODULE_PARM_DESC()|, 用于记录模块可以接受的参数。它接受两个参数：变量名和描述该变量的自由格式字符串。
最后, 有一个宏函数\cpp|MODULE_PARM_DESC()|, 用于记录模块可以接受的参数。它接受两个参数: 变量名和描述该变量的自由格式字符串。
\samplec{examples/hello-5.c}
@ -505,25 +505,25 @@ clean:
\subsection{为预编译内核构建模块}
\label{precompiled}
我们强烈建议您重新编译内核, 以便您可以启用许多有用的调试功能, 例如强制模块卸载(\cpp|MODULE_FORCE_UNLOAD|): 当启用此选项时, 您可以通过\sh|sudo rmmod -f module|命令强制内核卸载模块, 即使它认为模块不安全。在模块开发过程中, 此选项可以节省大量时间和多次重新启动。如果不想重新编译内核, 则应该考虑在虚拟机上的测试发行版中运行这些示例。如果您搞坏了什么, 可以快速重新启动或恢复虚拟机（VM）。
我们强烈建议你重新编译内核, 以便你可以启用许多有用的调试功能, 例如强制模块卸载(\cpp|MODULE_FORCE_UNLOAD|): 当启用此选项时, 你可以通过\sh|sudo rmmod -f module|命令强制内核卸载模块, 即使它认为模块不安全。在模块开发过程中, 此选项可以节省大量时间和多次重新启动。如果不想重新编译内核, 则应该考虑在虚拟机上的测试发行版中运行这些示例。如果你搞坏了什么, 可以快速重新启动或恢复虚拟机(VM)。
在许多情况下, 您可能希望将模块加载到预编译的运行内核中, 例如常见Linux发行版附带的内核, 或者您过去编译过的内核。在某些情况下, 您可能需要编译模块并将其插入到不允许重新编译的正在运行的内核中, 或者在不希望重新启动的机器上。如果您想不出一种情况会迫使您为预编译内核使用模块, 那么您可能想跳过本节剩下的内容, 并将本节的其余部分视为一个大脚注。
在许多情况下, 你可能希望将模块加载到预编译的运行内核中, 例如常见Linux发行版附带的内核, 或者你过去编译过的内核。在某些情况下, 你可能需要编译模块并将其插入到不允许重新编译的正在运行的内核中, 或者在不希望重新启动的机器上。如果你想不出一种情况会迫使你为预编译内核使用模块, 那么你可能想跳过本节剩下的内容, 并将本节的其余部分视为一个大脚注。
如果您只是安装内核源代码树(kernel source tree), 请使用它来编译内核模块, 然后尝试将模块插入内核, 在大多数情况下, 您将获得如下错误:
如果你只是安装内核源代码树(kernel source tree), 请使用它来编译内核模块, 然后尝试将模块插入内核, 在大多数情况下, 你将获得如下错误:
\begin{verbatim}
insmod: ERROR: could not insert module poet.ko: Invalid module format
报错翻译： insmod: 错误:无法插入poet.ko模块: 无效的模块格式
报错翻译: insmod: 错误:无法插入poet.ko模块: 无效的模块格式
\end{verbatim}
一些隐秘信息被记录到systemd日志中:
\begin{verbatim}
kernel: poet: disagrees about version of symbol module_layout
报错翻译：kernel: poet: 对 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|：
换句话说, 内核拒绝接受模块, 因为版本信息(更准确的翻译应该是 \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
@ -539,9 +539,9 @@ vermagic: 5.4.0-70-generic SMP mod_unload modversions
为了克服这个问题, 我们可以使用\verb|--force-vermagic|选项, 但这种解决方案可能是不安全的, 并且在生产环境中是不可接受的。因此, 我们希望在与构建预编译内核的环境相同的环境中编译模块。如何做到这一点, 是本章其余部分的主题。
首先, 确保有一个内核源代码树可用, 其版本与当前内核完全相同。然后, 找到用于编译预编译内核的配置文件。这通常在\verb|/boot|目录下, 文件名类似于 \verb|config-5.14.x|。你可能只需将其复制到内核源代码树中：执行命令 \sh|cp /boot/config-`uname -r` .config| 。
首先, 确保有一个内核源代码树可用, 其版本与当前内核完全相同。然后, 找到用于编译预编译内核的配置文件。这通常在\verb|/boot|目录下, 文件名类似于 \verb|config-5.14.x|。你可能只需将其复制到内核源代码树中: 执行命令 \sh|cp /boot/config-`uname -r` .config| 。
观察之前的版本信息, 即使两个配置文件完全相同, 版本信息还是可能会出现一些差异阻止模块插入到内核中。这种差异是由于对某些发行版修改了Makefile中定义的版本信息所致。查看你的内核源码根目录下的Makefile, 确保指定的版本信息与当前内核使用的完全匹配。发行版的\verb|Makefile|是类似如下格式：
观察之前的版本信息, 即使两个配置文件完全相同, 版本信息还是可能会出现一些差异阻止模块插入到内核中。这种差异是由于对某些发行版修改了Makefile中定义的版本信息所致。查看你的内核源码根目录下的Makefile, 确保指定的版本信息与当前内核使用的完全匹配。发行版的\verb|Makefile|是类似如下格式:
\begin{verbatim}
VERSION = 5
@ -555,9 +555,9 @@ EXTRAVERSION = -rc2
\begin{codebash}
cp /lib/modules/`uname -r`/build/Makefile linux-`uname -r`
\end{codebash}
\sh|linux-`uname -r`| 是您试图构建的linux内核源代码, 可以之间在命令行中执行 \sh|`uname -r`| 查看返回值。
\sh|linux-`uname -r`| 是你试图构建的linux内核源代码, 可以之间在命令行中执行 \sh|`uname -r`| 查看返回值。
最后, 请运行make来更新配置、头文件：
最后, 请运行make来更新配置、头文件:
\begin{verbatim}
$ make
@ -576,7 +576,7 @@ $ make
HOSTLD scripts/kconfig/conf
\end{verbatim}
如果你不想编译完整的内核, 在SPLIT行之后中断构建 (CTRL-C) 即可, 后续返回到模块的目录并编译模块即可：它将完全根据您当前的内核设置构建, 并且它将在没有任何错误的情况下加载。
如果你不想编译完整的内核, 在SPLIT行之后中断构建 (CTRL-C) 即可, 后续返回到模块的目录并编译模块即可: 它将完全根据你当前的内核设置构建, 并且它将在没有任何错误的情况下加载。
\section{准备工作}
\subsection{模块开始和结束方式}
@ -592,12 +592,12 @@ $ make
\label{sec:avail_func}
程序员经常使用不是自己定义的函数。这方面的一个常见的例子是 \cpp|printf()|。在使用标准C库libc提供的这些库函数实际上直到链接阶段才会进入你的程序, 这确保代码(例如 \cpp|printf()|的代码)可用, 并将调用指令指向那段代码。
内核模块在这里也有所不同。在"Hello World"示例中, 您可能注意到我们使用了函数\cpp|pr_info()|, 但没有包括标准I/O库。这是因为模块是对象文件, 其符号在运行\sh|insmod| 或 \sh|modprobe|时得到解析。符号的定义来自内核本身；您只能使用内核提供的外部函数。如果你对内核已导出的符号感兴趣, 可以查看\verb|/proc/kallsyms|。
内核模块在这里也有所不同。在"Hello World"示例中, 你可能注意到我们使用了函数\cpp|pr_info()|, 但没有包括标准I/O库。这是因为模块是对象文件, 其符号在运行\sh|insmod| 或 \sh|modprobe|时得到解析。符号的定义来自内核本身；你只能使用内核提供的外部函数。如果你对内核已导出的符号感兴趣, 可以查看\verb|/proc/kallsyms|。
需要记住的一点是库函数和系统调用之间的区别。库函数是更上层的, 完全在用户空间中运行, 并为程序员提供了一个更方便的接口, 以实现真正的工作系统调用。
系统调用代表用户在内核模式下运行, 并由内核本身提供。库函数\cpp|printf()|可能看起来像一个非常通用的打印函数, 但它真正做的只是将数据格式化为字符串, 并使用底层系统调用\cpp|write()|写入字符串数据, 然后将数据发送到标准输出。
可以使用下述方法看看\cpp|printf()|都进行了那些系统调用。编译以下程序：
可以使用下述方法看看\cpp|printf()|都进行了那些系统调用。编译以下程序:
\begin{code}
#include <stdio.h>
@ -609,18 +609,18 @@ int main(void)
}
\end{code}
使用 \sh|gcc -Wall -o hello hello.c|。使用 \sh|strace ./hello| 运行可执行文件。您看到的每一行都对应于一个系统调用。
使用 \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()|）。
如果想要了解更详细的信息可以查看 \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, 也称为“内核模式”, 其中允许所有操作）和最低环, 称为“用户模式”。
为了管理这些资源, CPU 在不同模式下运行, 每个模式都提供不同级别的系统控制。例如, 英特尔的80386架构就具有四种这样的模式, 称为环。然而, Unix仅使用其中两个环: 最高环(环0, 也称为“内核模式”, 其中允许所有操作)和最低环, 称为“用户模式”。
回顾关于库函数与系统调用的讨论。通常会在用户模式下使用库函数。库函数调用一个或多个系统调用, 并且这些系统调用以库函数的名义执行, 但在内核模式下执行, 因为它们是内核本身的一部分。一旦系统调用完成其任务, 它将返回, 并将执行权转交回用户模式。
@ -628,7 +628,7 @@ int main(void)
\label{sec:namespace}
当你在编写一个小规模项目时, 使用通俗易懂的变量名通常是为了增加程序的可读性。但如果参与一个多人维护的庞大项目, 你的全局变量会和其他人的全局变量共存, 可能会出现全局变量名冲突的情况。当一个程序拥有大量全局变量且这些变量名不足以准确描述其用途时, 就会出现命名空间污染。在大型团队项目中, 在确保能记住保留的名称的同时, 需要找到一种制定方案, 以便为变量名和符号命名保持唯一性。
在编写内核代码时, 即使是最小的模块也会链接到整个内核, 因此需要避免命名空间污染这个问题。处理此问题的最佳方法是将所有变量声明为静态, 并使用一个精准不会重复的前缀。按照惯例, 所有内核前缀都是小写的。如果您不想将所有内容都声明为静态, 另一个方法是声明符号表并将其注册到内核。我们稍后将讨论这个问题。
在编写内核代码时, 即使是最小的模块也会链接到整个内核, 因此需要避免命名空间污染这个问题。处理此问题的最佳方法是将所有变量声明为静态, 并使用一个精准不会重复的前缀。按照惯例, 所有内核前缀都是小写的。如果你不想将所有内容都声明为静态, 另一个方法是声明符号表并将其注册到内核。我们稍后将讨论这个问题。
文件 \verb|/proc/kallsyms|包含了内核所知道的所有符号, 因此这些符号对你的模块来说是可访问的, 因为它们共享了内核的代码空间。
@ -636,19 +636,19 @@ int main(void)
\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”程序这样的进程不能访问其他进程的空间, 我们稍后会讨论一些可以做到这一点的方法。
如果你没有深入思考过段错误(segfault)的真正含义, 你可能会惊讶地发现指针并不真正指向内存位置——至少不是真实的内存位置。当一个进程被创建时, 内核会划分一部分真实的物理内存并分配给该进程, 用于其执行代码、变量、栈、堆以及计算机科学家所熟知的其他内容。这部分内存从0x00000000开始, 延伸到所需的任何地址。由于任何两个进程的内存空间不会重叠, 任何可以访问某个内存地址(比如0xbffff978)的进程, 实际上访问的是物理内存中的不同位置！这些进程实际上访问的是名为0xbffff978的索引, 该索引指向为该特定进程预留的内存区域中的某个偏移量。大多数情况下, 像我们的“Hello, World”程序这样的进程不能访问其他进程的空间, 我们稍后会讨论一些可以做到这一点的方法。
内核也有自己的内存空间。由于模块是可以在内核中动态插入和删除的代码(与半独立对象相反), 因此它共享内核的代码空间, 而不是拥有自己的代码空间。因此, 如果模块段出错, 则内核段出错。如果你因为一个“边界错误(off-by-one)”开始覆写数据, 那么您就是在破坏内核数据(或代码)。这种情况比听起来的还要危险, 所以尽量小心处理。
内核也有自己的内存空间。由于模块是可以在内核中动态插入和删除的代码(与半独立对象相反), 因此它共享内核的代码空间, 而不是拥有自己的代码空间。因此, 如果模块段出错, 则内核段出错。如果你因为一个“边界错误(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)}。
应当注意, 上述讨论适用于任何使用单块式内核(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，而无需知道安装了何种声卡。
有一类模块是设备驱动程序, 它为硬件(如串行端口)提供功能。在Unix上, 每个硬件都通过位于\verb|/dev|目录下的设备文件来表示, 这些文件提供了与硬件通信的手段。设备驱动程序代表用户程序提供通信。因此, es1370.ko声卡设备驱动程序可以将/dev/sound设备文件连接到Ensoniq ES1370声卡。像mp3blaster这样的用户空间程序可以使用/dev/sound, 而无需知道安装了何种声卡。
我们可以看一些设备文件。以下是表示串行端口(tty-teletypewriter)上的前三个端口的设备文件：
我们可以看一些设备文件。以下是表示串行端口(tty-teletypewriter)上的前三个端口的设备文件:
\begin{verbatim}
$ ls -l /dev/tty[1-3]
@ -657,11 +657,11 @@ 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，因为它们都由同一个驱动程序控制。
请注意日期前方由逗号分隔的数字列(4, 1 ; 4, 2 ; 4, 3)。第一个数字称为设备的主编号。第二个数字是次要数字。主编号告诉你使用哪个驱动程序访问硬件。每个驱动程序都有唯一的一个主编号码；主编号码相同的设备文件都由同一个驱动程序控制。上述所有主编号码都是 4, 因为它们都由同一个驱动程序控制。
次要编号由驱动程序用于区分其控制的各种硬件。回到上面的例子，尽管所有三个设备都由相同的驱动程序处理，但它们具有唯一的次要编号，因为驱动程序将它们视为不同的硬件。
次要编号由驱动程序用于区分其控制的各种硬件。回到上面的例子, 尽管所有三个设备都由相同的驱动程序处理, 但它们具有唯一的次要编号, 因为驱动程序将它们视为不同的硬件。
设备分为两种类型：字符设备和块设备。区别在于块设备具有请求的缓冲区，因此它们可以选择响应请求的最佳顺序。这一点对存储设备尤为重要，因为读写相邻的扇区比读写距离较远的扇区更快。另一个区别是，块设备只能按块接收输入和返回输出（块的大小可以根据设备而变），而字符设备则可以按需要使用任意数量的字节。世界上大多数设备都是字符型的，它们不需要这种缓冲不以固定的块大小运行。您可以通过查看\sh|ls -l|输出中的第一个字符来判断设备文件是用于块设备还是字符设备。如果它是“b”，则它是块设备，如果它是c，则它为字符设备。上面看到的设备是字符设备。以下是一些块设备（存储）：
设备分为两种类型: 字符设备和块设备。区别在于块设备具有请求的缓冲区, 因此它们可以选择响应请求的最佳顺序。这一点对存储设备尤为重要, 因为读写相邻的扇区比读写距离较远的扇区更快。另一个区别是, 块设备只能按块接收输入和返回输出(块的大小可以根据设备而变), 而字符设备则可以按需要使用任意数量的字节。世界上大多数设备都是字符型的, 它们不需要这种缓冲不以固定的块大小运行。你可以通过查看\sh|ls -l|输出中的第一个字符来判断设备文件是用于块设备还是字符设备。如果它是“b”, 则它是块设备, 如果它是c, 则它为字符设备。上面看到的设备是字符设备。以下是一些块设备(存储):
\begin{verbatim}
brw-rw---- 1 root disk 7, 0 7月28日 15:44 loop0
@ -679,36 +679,29 @@ 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}。
如果要查看已分配的主编号, 可以查看\src{Documentation/admin-guide/devices.txt}。
安装系统时，所有设备文件都是通过\sh|mknod|命令创建的。要创建一个名为\verb|coffee|的新字符设备，主为12和次为2，只需执行\sh|mknod /dev/coffee c 12 2|。您不必将设备文件放入\verb|/dev|中，但这是按照约定完成的。Linus将他的设备文件放在\verb|/dev|中，您也应该这样。然而，当为测试目的创建设备文件时，将其放置在你编译内核模块的工作目录中通常是可以的。但完成设备驱动程序编写后，确保将其放在正确的位置。
安装系统时, 所有设备文件都是通过\sh|mknod|命令创建的。要创建一个名为\verb|coffee|的新字符设备, 主为12和次为2, 只需执行\sh|mknod /dev/coffee c 12 2|。你不必将设备文件放入\verb|/dev|中, 但这是按照约定完成的。Linus将他的设备文件放在\verb|/dev|中, 你也应该这样。然而, 当为测试目的创建设备文件时, 将其放置在你编译内核模块的工作目录中通常是可以的。但完成设备驱动程序编写后, 确保将其放在正确的位置。
最后需要明确的是当访问设备文件时，内核使用该文件的主设备号来识别处理访问对应的驱动程序。这意味着内核不必依赖或了解次设备号。处理次设备号的是驱动程序本身，它用次设备号来区分不同的硬件设备。
最后需要明确的是当访问设备文件时, 内核使用该文件的主编号来识别处理访问对应的驱动程序。这意味着内核不必依赖或了解次设备号。处理次设备号的是驱动程序本身, 它用次设备号来区分不同的硬件设备。
需要注意的是，当提到“\emph{``硬件(hardware)''}”时，该术语的使用稍微抽象一些，他指的不仅仅是PCI设备。看看以下两个设备文件：
需要注意的是, 当提到“\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
brw-rw---- 1 root disk 8, 0 7月28日 15:44 /dev/sda
\end{verbatim}
现在，您可以查看这两个设备文件，并立即知道它们是块设备，并且由相同的驱动程序处理(块, 主259)。有时，具有相同主编号但不同次编号的两个设备文件实际上可以表示相同的物理硬件。所以请注意，我们讨论中的“硬件”一词可能意味着非常抽象的东西。
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.
从这两个设备文件的信息你应该能看出它们是块设备, 并且他们是由相同的驱动程序处理(块, 主259)。但是上述具有相同主编号但不同次号的两个设备文件实际上是表示相同的物理硬件。所以请注意, 我们讨论中的“\emph{“硬件(hardware)”}”一词可能意味着一些抽象的东西。
\section{Character Device drivers}
\section{字符设备驱动程序}
\label{sec:chardev}
\subsection{The file\_operations Structure}
\subsection{文件操作结构}
\label{sec:file_operations}
The \cpp|file_operations| structure is defined in \src{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.
\cpp|file_operations|结构在\src{include/linux/fs.h}中定义并保存指向驱动程序定义的函数的指针, 这些函数在设备上执行各种操作。结构的每个字段对应于驱动程序定义的某个函数的地址, 以处理请求的操作。
For example, every character driver needs to define a function that reads from the device.
The \cpp|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:
每个字符驱动程序都需要定义从设备读取的函数。\cpp|file_operations|结构保存执行该操作的模块函数的地址。下面是内核5.4的定义:
\begin{code}
struct file_operations {
@ -751,13 +744,9 @@ struct file_operations {
} __randomize_layout;
\end{code}
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 \cpp|file_operations| structure should be set to \cpp|NULL|.
一些操作不是由驱动程序实现的。例如, 显卡的驱动程序不需要从目录结构中读取(ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);)。\cpp|file_operations|结构中的相应条目应设置为\cpp|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:
有一个GCC扩展使分配到此结构更方便。你会在现代的驱动程序中看到它, 这可能会让你感到意外。下面是这种新方式对结构赋值的样子:
\begin{code}
struct file_operations fops = {
@ -768,9 +757,7 @@ struct file_operations fops = {
};
\end{code}
However, there is also a C99 way of assigning to elements of a structure, \href{https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html}{designated initializers}, 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:
但也有一种更常用基于C99标准的方式来分配结构元素, 即\href{https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html}{指定初始化器(designated initializers)}, 与使用GNU扩展相比这种基于C99的分配方法适用性更加广泛。使用此语法有助于增加驱动的兼容性:
\begin{code}
struct file_operations fops = {
@ -781,159 +768,103 @@ struct file_operations fops = {
};
\end{code}
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 \cpp|NULL| by gcc.
没有显式分配的结构的任何成员都将由GCC初始化为 \cpp|NULL|。
An instance of \cpp|struct file_operations| containing pointers to functions that are used to implement \cpp|read|, \cpp|write|, \cpp|open|, \ldots{} system calls is commonly named \cpp|fops|.
结构 \cpp|struct file_operations| 的实例包含指向用于实现 \cpp|读取(read)|, \cpp|写入(write)|, \cpp|打开(open)|, \ldots{}系统调用的函数的指针, 通常称为\cpp|fops|。
Since Linux v3.14, the read, write and seek operations are guaranteed for thread-safe by using the \cpp|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.
从 Linux v3.14 开始, 通过使用特定的 f_pos 锁, 读、写和寻址操作保证了线程安全, 这使得文件位置的更新变成了互斥操作。因此, 我们可以在不需要额外加锁的情况下安全地实现这些操作。
Additionally, since Linux v5.6, the \cpp|proc_ops| structure was introduced to replace the use of the \cpp|file_operations| structure when registering proc handlers.
See more information in the \ref{sec:proc_ops} section.
此外, 从Linux v5.6开始, 引入了 \cpp|proc_ops| 结构, 以取代在注册proc处理程序时使用的 \cpp|file_operations|结构。请参阅\ref{sec:proc_ops}节中的更多信息。
\subsection{The file structure}
\subsection{文件结构}
\label{sec:file_struct}
Each device is represented in the kernel by a file structure, which is defined in \src{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 \cpp|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 \cpp|inode|.
每个设备在内核中由一个文件结构表示, 该文件结构在 \src{include/linux/fs.h}中定义。这里的文件是内核级结构, 从不出现在用户空间程序中。他与我们常见的由\cpp|glibc|定义\cpp|FILE|是不同的, 由\cpp|glibc|定义的\cpp|FILE|不会出现在内核空间函数中。内核这里的文件(file)命名会产生一些误导；它表示一个抽象的打开“文件(file)”, 而不是磁盘上的文件, 该文件由一个名为\cpp|inode|的结构表示。
An instance of struct file is commonly named \cpp|filp|.
You'll also see it referred to as a struct file object.
Resist the temptation.
内核中的结构体 \cpp|文件(file)| 实例通常被称为 filp。你也会看到它被称为 \cpp|结构体文件对象(struct file object)|。不要随意更改这种叫法。
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.
查看 file 的定义会发现, 大多数条目(如structdentry)并不被设备驱动程序使用, 因此可以忽略它们。这是因为驱动程序并不直接填充 file 结构；它们只使用在其他地方创建的 file 结构中包含的子结构。
\subsection{Registering A Device}
\subsection{注册设备}
\label{sec:register_device}
As discussed earlier, char devices are accessed through device files, usually located in \verb|/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 \verb|/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.
如之前所讨论的, 按照约定俗成的做法字符设备通过位于 \verb|/dev| 目录下的设备文件来访问。在编写驱动程序时, 将设备文件放在当前目录是可以的。但请确保在生产环境中将其放置在 \verb|/dev| 目录。主编号用于标识哪个驱动程序处理哪个设备文件。次号仅由驱动程序本身使用, 在一个驱动程序处理多个设备时区分它正在操作的设备。
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 \cpp|register_chrdev| function, defined by \src{include/linux/fs.h}.
向系统中添加驱动程序意味着向内核注册它。这等同于在模块初始化期间为其分配主编号。你可以通过使用 \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|。因为内核不关心次号, 只有我们的驱动使用它。
Where unsigned int major is the major number you want to request, \cpp|const char *name| is the name of the device as it will appear in \verb|/proc/devices| and \cpp|struct file_operations *fops| is a pointer to the \cpp|file_operations| table for your driver.
A negative return value means the registration failed. Note that we didn't pass the minor number to \cpp|register_chrdev|.
That is because the kernel doesn't care about the minor number; only our driver uses it.
现在的问题是, 如何获得一个不占用已经在使用中的主编号？最简单的方法是查看 \src{Documentation/admin-guide/devices.txt} 文件选择一个未被使用的编号。但这种做法并不理想, 因为你无法确保你选择的号码以后不会被分配。正确的做法是请求内核为你分配一个动态的主编号。
如果传递给 \cpp|register_chrdev|的值是0, 返回值将是动态分配的主编号。不过, 这样做的缺点是你无法提前创建设备文件, 因为你不知道将会获得什么主编号。处理这种情况有几种方法: 驱动程序本身可以打印新分配的编号, 我们可以手动制作设备文件; 新注册的设备将在\verb|/proc/devices|中有一个条目, 我们可以手动创建设备文件, 也可以编写一个shell脚本来读取文件并创建设备文件; 还有一种方法是, 我们可以让驱动程序在成功注册后使用 \cpp|device_create|函数生成设备文件, 并在调用 \cpp|cleanup_module|期间使用\cpp|device_destroy|。
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 \src{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.
\cpp|register_chrdev()| 函数会占用与指定主编号相关联的一系列次设备号。为了减少字符设备注册时的资源浪费, 推荐使用 cdev 接口。
If you pass a major number of 0 to \cpp|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 \verb|/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 \cpp|device_create| function after a successful registration and \cpp|device_destroy| during the call to \cpp|cleanup_module|.
However, \cpp|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 \cpp|register_chrdev_region| or \cpp|alloc_chrdev_region|.
新接口通过两个步骤完成字符设备的注册。首先注册一系列设备号, 可以用\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}
The choice between two different functions depends on whether you know the major numbers for your device.
Using \cpp|register_chrdev_region| if you know the device major number and \cpp|alloc_chrdev_region| if you would like to allocate a dynamically-allocated major number.
两种不同功能之间的选择取决于你是否知道设备的主编号。如果知道设备主编号, 则使用\cpp|register_chrdev_region|；如果要分配动态分配的主编号, 请使用\cpp|alloc_chrdev_region|。
Second, we should initialize the data structure \cpp|struct cdev| for our char device and associate it with the device numbers.
To initialize the \cpp|struct cdev|, we can achieve by the similar sequence of the following codes.
其次, 我们应该初始化字符驱动的数据结构\cpp|struct cdev|并将其与设备号相关联。初始化 \cpp|struct cdev| 的代码序列可以参照以下示例来实现。
\begin{code}
struct cdev *my_dev = cdev_alloc();
my_cdev->ops = &my_fops;
\end{code}
However, the common usage pattern will embed the \cpp|struct cdev| within a device-specific structure of your own.
In this case, we'll need \cpp|cdev_init| for the initialization.
通常的做法是将 \cpp|struct cdev| 嵌入到设备特定的结构中。在这种情况下, 我们需要使用 \cpp|cdev_init| 来进行初始化。
\begin{code}
void cdev_init(struct cdev *cdev, const struct file_operations *fops);
\end{code}
Once we finish the initialization, we can add the char device to the system by using the \cpp|cdev_add|.
一旦完成初始化, 就可以使用\cpp|cdev_add|将字符驱动添加到系统中。
\begin{code}
int cdev_add(struct cdev *p, dev_t dev, unsigned count);
\end{code}
To find an example using the interface, you can see \verb|ioctl.c| described in section \ref{sec:device_files}.
要查找使用该接口的示例, 可以参阅第\ref{sec:device_files}节中描述的\verb|ioctl.c|。
\subsection{Unregistering A Device}
\subsection{注销设备}
\label{sec:unregister_device}
We can not allow the kernel module to be \sh|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.
我们不能让内核模块在root的情况下随意使用 \sh|rmmod| 删除模块。如果有一个进程打开了设备文件, 然后我们移除了内核模块, 再使用该文件将会导致调用已删除函数(如读/写)的内存位置。如果幸运的话, 那里没有加载其他代码, 我们将收到一条错误消息。如果我们运气不好, 另一个内核模块被加载到相同的位置, 这意味着跳转到内核中另一个函数的中间。这种情况的结果是无法预测的, 但肯定不会有什么好结果。
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 \cpp|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 \sh|cat /proc/modules| or \sh|sudo lsmod|.
If this number isn't zero, \sh|rmmod| will fail.
Note that you do not have to check the counter within \cpp|cleanup_module| because the check will be performed for you by the system call \cpp|sys_delete_module|, defined in \src{include/linux/syscalls.h}.
You should not use this counter directly, but there are functions defined in \src{include/linux/module.h} which let you increase, decrease and display this counter:
当你不想允许某些操作时, 应该从尝试执行该操作的函数返回一个错误代码(一个负数)。但 \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)|: Increment the reference count of current module.
\item \cpp|module_put(THIS_MODULE)|: Decrement the reference count of current module.
\item \cpp|module_refcount(THIS_MODULE)|: Return the value of reference count of current module.
\item \cpp|try_module_get(THIS_MODULE)|: 增加当前模块的引用计数。
\item \cpp|module_put(THIS_MODULE)|: 减少当前模块的引用计数。
\item \cpp|module_refcount(THIS_MODULE)|: 返回当前模块的引用计数的值。
\end{itemize}
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.
保持计数器的准确性是很重要的时期, 如果你让计数器数值出现了异常可能会导致模块永远无法被卸载了, 朋友如果你碰到这种情况了, 那只能靠重启来解决问题了。不过在模块开发过程中, 这种情况迟早会发生。
\subsection{chardev.c}
\label{sec:chardev_c}
The next code sample creates a char driver named \verb|chardev|.
You can dump its device file.
下一个代码示例创建一个名为\verb|chardev|的字符驱动程序。你可以转储其设备文件。
\begin{codebash}
cat /proc/devices
\end{codebash}
(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 \sh|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.
驱动程序会将设备文件被读取(或用程序打开文件)的次数记录到文件中。这里不支持写入文件(如 \sh|echo "hi" > /dev/hello|), 但会捕获这些尝试并告诉用户该操作不被支持。不用担心为什么你没有看到这里对读入缓冲区的数据进行了什么操作，因为并没有什么处理。这里只是简单地读入数据后打印一条消息来确认我们收到了它。
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, \cpp|CDEV_NOT_USED| and \cpp|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 \ref{sec:synchronization} section.
在多线程环境中, 如果没有任何保护, 对同一内存的并发访问可能会导致争用情况, 并且会影响性能。在内核模块中, 这个问题可能由于多个实例访问共享资源而发生。因此, 一种解决方案是强制独占访问。我们使用原子性的 CAS(比较和交换, Compare-And-Swap) 来维护状态\cpp|CDEV_NOT_USED| 和 \cpp|CDEV_EXCLUSIVE_OPEN| 以确定文件当前是否被打开。CAS将存储器位置的内容与期望值进行比较, 并且仅当它们相同时, 才将该存储器位置的内容修改为期望值。有关并发的更多细节，请参阅 \ref{sec:synchronization} 部分。
\samplec{examples/chardev.c}
\subsection{Writing Modules for Multiple Kernel Versions}
\subsection{为多个内核版本编写模块}
\label{sec:modules_for_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 \cpp|LINUX_VERSION_CODE| to the macro \cpp|KERNEL_VERSION|.
In version \verb|a.b.c| of the kernel, the value of this macro would be \(2^{16}a+2^{8}b+c\).
系统调用是进程调用内核的主要接口，在不同版本中通常保持不变。在添加新的系统调用时往往会保证旧的系统调用不会发生变化，这对于系统的向后兼容性是非常重要的。内核新版本不会破坏旧进程的正常运行。在大多数情况下，设备文件也应当保持不变。另一方面，内核内部的接口在不同版本之间会存在一些变化。
不同的内核版本之间存在差异, 如果想支持多个内核版本, 则需要编写条件编译指令。实现这一点的方法是比较 \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}