对于任何编写内核代码的人来说，最吸引他们注意的问题之一就是如何完成调试。
由于内核是一个不与某个进程相关的功能集，其代码不能很轻松地放在调试器中执
行，而且也不能跟踪。
本章介绍你可以用来监视内核代码和跟踪错误的技术。
用打印信息调试
最一般的调试技术就是监视，就是在应用内部合适的点加上printf调用。当你调试内
核代码的时候，你可以用printk完成这个任务。
Printk
在前些章中，我们简单假设printk工作起来和printf很类似。现在是介绍一下它们之间
不同的时候了。
其中一个不同点就是，printk允许你根据它们的严重程度，通过附加不同的“记录
级”来对消息分类，或赋予消息优先级。你可以用宏来指示记录级。例如，KERN_INFO，
我们前面已经看到它被加在打印语句的前面，它就是一种可能的消息记录级。记录
级宏展开为一个字串，在编译时和消息文本拼接在一起；这也就是为什么下面的例
子中优先级和格式字串间没有逗号。这有两个printk的例子，一个是调试信息，一个
是关键信息：
（代码）
在<linux/kernel.h>中定义了8种记录级别串。没有指定优先级的printk语句默认使用DEFAULT_MESSAGE_LOGLEVEL
优先级，它是一个在kernel/printk.c中定义的整数。默认记录级的具体数值在Linux的开
发期间曾变化过若干次，所以我建议你最好总是指定一个合适的记录级。
根据记录级，内核将消息打印到当前文本控制台上：如果优先级低于console_loglevel
这个数值的话，该消息就显示在控制台上。如果系统同时运行了klogd和syslogd，无
论console_loglevel为何值，内核都将消息追加到/var/log/messages中。
变量console_loglevel最初初始化为DEFAULT_CONSOLE_LOGLEVEL，但可以通过sys_syslog系
统调用修改。如klogd的手册所示，可以在启动klogd时指定-c开关来修改这个变量。
此外，你还可以写个程序来改变控制台记录级。你可以在O'Reilly站点上的源文件
中找到我写的一个这种功能的程序，miscprogs/setlevel.c。新优先级是通过一个1到8之
间的整数值指定的。
你也许需要在内核失效后降低记录级（见“调试系统故障”），这是因为失效处理
代码会将console_loglevel提升到15，之后所有的消息都会出现在控制台上。为看到你的
调试信息，如果你运行的是内核2.0.x话，你需要提升记录级。内核2.0发行降低了MINIMUM_CONSOLE_LOGLEVEL，
而旧版本的klogd默认情况下要打印很多控制消息。如果你碰巧使用了这个旧版本的
守护进程，除非你提升记录级，内核2.0会比你预期的打印出更少的消息。这就是为
什么hello.c中使用了<1>标记，这样可以保证消息显示在控制台上。
从1.3.43一来的内核版本通过允许你向指定虚控制台发送消息，藉此提供一个灵活的
记录策略。默认情况下，“控制台”是当前虚终端。也可以选择不同的虚终端接收
消息，你只需向所选的虚终端调用ioctl(TIOCLINUX)。如下程序，setconsole，可以用来
选择哪个虚终端接收内核消息；它必须以超级用户身份运行。如果你对ioctl还不有
把握，你可以跳过这至下一节，等到读完第5章“字符设备驱动程序的扩展操作”
的“ioctl”一节后，再回到这里读这段代码。
（代码）
setconsole使用了用于Linux专用功能的特殊的ioctl命令TIOCLINUX。为了使用TIOCLINUX，
你要传递给它一个指向字节数组的指针。数组的第一个字节是所请求的子命令的编
码，随后的字节依命令而不同。在setconsole中使用了子命令11，后一个字节（存放
在bytes[1]中）标别虚拟控制台。TIOCLINUX的完成介绍可以在内核[url=http://www.pccode.net].net" class="wordstyle"源码drivers/char/tty_io.c
中找到。
消息是如何记录的
printk函数将消息写到一个长度为LOG_BUF_LEN个字节的循环缓冲区中。然后唤醒任
何等待消息的进程，即那些在调用syslog系统调用或读取/proc/kmesg过程中睡眠的进
程。这两个访问记录引擎的接口是等价的。不过/proc/kmesg文件更象一个FIFO文件，
从中读取数据更容易些。一条简单的cat命令就可以读取消息。
如果循环缓冲区填满了，printk就绕到缓冲区的开始处填写新数据，覆盖旧数据。于
是记录进程就丢失了最旧的数据。这个问题与利用循环缓冲区所获得的好处相比可
以忽略不计。例如，循环缓冲区可以使系统在没有记录进程的情况下照样运行，同
时又不浪费内存。Linux处理消息的方法的另一个特点是，可以在任何地方调用printk，
甚至在中断处理函数里也可以调用，而且对数据量的大小没有限制。这个方法的唯
一缺点就是可能丢失某些数据。
如果klogd正在运行，它读取内核消息并将它们分派到syslogd，它随后检查/etc/syslog.conf
找到处理这些数据的方式。syslogd根据一个“设施”和“优先级”切分消息；可以
使用的值定义在<sys/syslog.h>中。内核消息根据相应printk中指定的优先级记录到LOG_KERN
设施中。如果klogd没有运行，数据将保存在循环缓冲区中直到有进程来读取数据或
数据溢出。
如果你不希望因监视你的驱动程序的消息而把你的系统记录搞乱，你给klogd指定-f
（文件）选项或修改/etc/syslog.conf将记录写到另一个文件中。另一种方法是一种强硬
方法：杀掉klogd，将消息打印到不用的虚终端上*，或者在一个不用的xterm上执行cat
/proc/kmesg显示消息。
使用预处理方便监视处理
在驱动程序开发早期，printk可以对调试和测试新代码都非常有帮助。然而当你正式
发行驱动程序时，你应该去掉，或者至少关闭，这些打印语句。很不幸，你可能很
快就发现，随着你想不再需要那些消息并去掉它们时，你可能又要加新功能，你又
需要这些消息了。解决这些问题有几种方法――如何从全局打开和关闭消息以及如
何打开和关闭个别消息。
下面给出了我处理消息所用的大部分代码，它有如下一些功能：
可以通过在宏名字加一个字母或去掉一个字母打开或关闭每一条语句。
通过在编译前修改CFLAGS变量，可以一次关闭所有消息。
同样的打印语句既可以用在内核态（驱动程序）也可以用在用户态（演示或
测试程序）。
下面这些直接来自scull.h的代码片断实现了这些功能。
（代码）
符合PDEBUG和PDEBUGG依赖于是否定义了SCULL_DEBUG，它们都和printf调用很类似。
为了进一步方便这个过程，在你的Makefile加上如下几行。
（代码）
本节所给出的代码依赖于gcc对ANSI C预编译器的扩展，gcc可以支持带可变数目参数
的宏。这种对gcc的依赖并不是什么问题，因为内核对gcc特性的依赖更强。此外，Makefile
依赖于GNU的gmake；基于同样的道理，这也不是什么问题。
如果你很熟悉C预编译器，你可以将上面的定义扩展为可以支持“调试级”概念
的，可以为每级赋一个整数（或位图），说明这一级打印多么琐碎的消息。
但是每一个驱动程序都有它自己的功能和监视需求。好的编程技巧会在灵活性和高
效之间找到一个权衡点，这个我就不能说哪个对你最好了。记住，预编译器条件
（还有代码中的常量表达式）只到编译时运行，你必须重新编译程序来打开或关闭
消息。另一种方法就是使用C条件语句，它在运行时运行，因此可以让你在程序执
行期间打开或关闭消息。这个功能很好，但每次代码执行系统都要进行额外的处
理，甚至在消息关闭后仍然会影响性能。有时这种性能损失是无法接受的。
个人观点，尽管上面给出的宏迫使你每次要增加或去掉消息时都要重新编译，重新
加载模块，但我觉得用这些宏已经很好了。
通过查询调试
上一节谈到了printk是如何工作的以及如何使用它。但没有谈及它的缺点。
由于syslogd会一直保持刷新它的输出文件，每打印一行都会引起一次磁盘操作，因
此过量使用printk会严重降低系统性能。至少从syslogd的角度看是这样的。它会将所
有的数据都一股脑地写到磁盘上，以防在打印消息后系统崩溃；然而，你不想因为
调试信息的缘故而降低系统性能。这个问题可以通过在/etc/syslogd.conf中记录文件的
名字前加一个波折号解决，但有时你不想修改你的配置文件。如果不这样，你还可
以运行一个非klogd的程序（如前面介绍的cat /proc/kmesg），但这样并不能为正常操作
提供一个合适的环境。
与这相比，最好的方法就是在你需要信息的时候，通过查询系统获得相关信息，而
不是持续不断地产生数据。事实上，每一个Unix系统都提供了很多工具用来获得系
统信息：ps，netstat，vmstat等等。
有许多技术适合与驱动程序开发人员查询系统，简而言之就是，在/proc下创建文件
和使用ioctl驱动程序方法。
使用/proc文件系统
Linux中的/proc文件系统与任何设备都没有关系――/proc中的文件都在被读取时有核心
创建的。这些文件都是普通的文本文件，它们基本上可由普通人理解，也可被工具
程序理解。例如，对于大多数Linux的ps实现而言，它都通过读取/proc文件系统获得进
程表信息的。/proc虚拟文件的创意已由若干现代操作系统使用，且非常成功。
/proc的当前实现可以动态创建i节点，允许用户模块为方便信息检索创建如何入口
点。
为了在/proc中创建一个健全的文件节点（可以read，write，seek等等），你需要定义file_operations
结构和inode_operations结构，后者与前者有类似的作用和尺寸。创建这样一个i节点比
起创建整个字符设备并没有什么不同。我们这里不讨论这个问题，如果你感兴趣，
你可以在[url=http://www.pccode.net].net" class="wordstyle"源码树fs/proc中获得进一步细节。
与大多数/proc文件一样，如果文件节点仅仅用来读，创建它们是比较容易的，我将
这里介绍这一技术。很不幸，这一技术只能在Linux 2.0及其后续版本中使用。
这里是创建一个称为/proc/scullmem文件的scull代码，这个文件用来获取scull使用的内存
信息。
（代码）
填写/proc文件非常容易。你的函数获取一个空闲页面填写数据；它将数据写进缓冲
区并返回所写数据的长度。其他事情都由/proc文件系统处理。唯一的限制就是所写
的数据不能超过PAGE_SIZE个字节（宏PAGE_SIZE定义在头文件<asm/page.h>中；它是与
体系结构相关的，但你至少可以它有4KB大小）。
如果你需要写多于一个页面的数据，你必须实现功能健全的文件。
注意，如果一个正在读你的/proc文件的进程发出了若干read调用，每一个都获取新数
据，尽管只有少量数据被读取，你的驱动程序每次都要重写整个缓冲区。这些额外
的工作会使系统性能下降，而且如果文件产生的数据与下一次的不同，以后的read
调用要重新装配不相关的部分，这一会造成数据错位。事实上，由于每个使用C库
的应用程序都大块地读取数据，性能并不是什么问题。然而，由于错位时有发生，
它倒是一个值得考虑的问题。在获取数据后，库调用至少要调用1次read――只有当read
返回0时才报告文件尾。如果驱动程序碰巧比前面产生了更多的数据，系统就返回
到用户空间额外的字节并且与前面的数据块是错位的。我们将在第6章“时间流”
的“任务队列”一节中涉及/proc/jiq*，那时我们还会遇到错位问题。
cleanup_module中应该使用下面的语句注销/proc节点：
（代码）
传递给函数的参数是包含要撤销文件的目录名和文件的i节点号。由于i节点号是自
动分配的，在编译时是无法知道的，必须从数据结构中读取。
ioctl方法
ioctl，下一章将详细讨论，是一个系统调用，它可以操做在文件描述符上；它接收
一个“命令”号和（可选的）一个参数，通常这是一个指针。
做为替代/proc文件系统的方法，你可以为调试实现若干ioctl命令。这些命令从驱动程
序空间复制相关数据到进程空间，在进程空间里检查这些数据。
只有使用ioctl获取信息比起/proc来要困难一些，因为你一个程序调用ioctl并显示结
果。必须编写这样的程序，还要编译，保持与你测试的模块间的一致性等。
不过有时候这是最好的获取信息的方法，因为它比起读/proc来要快得多。如果在数
据写到屏幕前必须完成某些处理工作，以二进制获取数据要比读取文本文件有效得
多。此外，ioctl不限制返回数据的大小。
ioctl方法的一个优点是，当调试关闭后调试命令仍然可以保留在驱动程序中。/proc文
件对任何查看这个目录的人都是可见的，然而与/proc文件不同，未公开的ioctl命令通
常都不会被注意到。此外，如果驱动程序有什么异常，它们仍然可以用来调试。唯
一的缺点就是模块会稍微大一些。
通过监视调试
有时你遇到的问题并不特别糟，通过在用户空间运行应用程序来查看驱动程序与系
统之间的交互过程可以帮助你捕捉到一些小问题，并可以验证驱动程序确实工作正
常。例如，看到scull的read实现如何处理不同数据量的read请求后，我对scull更有信
心。
有许多方法监视一个用户态程序的工作情况。你可以用调试器一步步跟踪它的函
数，插入打印语句，或者用strace运行程序。在实际目的是查看内核代码时，最后一
项技术非常有用。
strace命令是一个功能非常强大的工具，它可以现实程序所调用的所有系统调用。它
不仅可以显示调用，而且还能显示调用的参数，以符号方式显示返回值。当系统调
用失败时，错误的符号值（如，ENOMEM）和对应的字串（Out of memory）同时显
示。strace还有许多命令行选项；最常用的是-t，它用来显示调用发生的时间，-T，
显示调用所花费的时间，以及-o，将输出重定向到一个文件中。默认情况下，strace
将所有跟踪信息打印到stderr上。
strace从内核接收信息。这意味着一个程序无论是否按调试方式编译（用gcc的-g选
项）或是被去掉了符号信息都可以被跟踪。与调试器可以连接到一个运行进程并控
制它类似，你还可以跟踪一个已经运行的进程。
跟踪信息通常用来生成错误报告报告给应用开发人员，但是对内核编程人员来说也
一样非常有用。我们可以看到系统调用是如何执行驱动程序代码的；strace允许我们
检查每一次调用输入输出的一致性。
例如，下面的屏幕输出给出了命令ls /dev > /dev/scull0的最后几行：
（代码）
很明显，在ls完成目标目录的检索后首次对write的调用中，它试图写4KB。很奇怪，
只写了4000个字节，接着重试这一操作。然而，我们知道scull的write实现每次只写一
个量子，我在这里看到了部分写。经过若干步骤之后，所有的东西都清空了，程序
正常退出。
另一个例子，让我们来读scull设备：
（代码）
正如所料，read每次只能读到4000个字节，但是数据总量是不变的。注意本例中重试
工作是如何组织的，注意它与上面写跟踪的对比。wc专门为快速读数据进行了优
化，它绕过了标准库，以便每次用一个系统调用读取更多的数据。你可以从跟踪的read
行中看到wc每次要读16KB。
Unix专家可以在strace的输出中找到很多有用信息。如果你被这些符号搞得满头雾
水，我可以只看文件方法（open，read等等）是如何工作的。
个人认为，跟踪工具在查明系统调用的运行时错误过程中最有用。通常应用或演示
程序中的perror调用不足以用来调试，而且对于查明到底是什么样的参数触发了系统
调用的错误也很有帮助。
调试系统故障
即便你用了所有监视和调试技术，有时候驱动程序中依然有错误，当这样的驱动程
序执行会造成系统故障。当这种情况发生时，获取足够多的信息来解决问题是至关
重要的。
注意，“故障”不意味着“panic”。Linux代码非常鲁棒，可以很好地响应大部分错
误：故障通常会导致当前进程的终止，但系统继续运行。如果在进程上下文之外发
生故障，或是组成系统的重要部件发生故障时，系统可能panic。但问题出在驱动程
序时，通常只会导致产生故障的进程终止――即那个使用驱动程序的进程。唯一不
可恢复的损失就是当进程被终止时，进程上下文分配的内存丢失了；例如，由驱动
程序通过kmalloc分配的动态链表可能丢失。然而，由于内核会对尚是打开的设备调
用close，你的驱动程序可以释放任何有open方法分配的资源。
我们已经说过，当内核行为异常时会在控制台上显示一些有用的信息。下一节将解
释如何解码和使用这些消息。尽管它们对于初学者来说相当晦涩，处理器的给出数
据都是些很有意思的信息，通常无需额外测试就可以查明程序错误。
Oops消息
大部分错误都是NULL指针引用或使用其他不正确的指针数值。这些错误通常会导致
一个oops消息。
由处理器使用的地址都是“虚”地址，而且通过一个复杂的称为页表（见第13章“Mmap
和DMA”中的“页表”一节）的结构映射为物理地址。当引用一个非法指针时，页
面映射机制就不能将地址映射到物理地址，并且处理器向操作系统发出一个“页面
失效”。如果地址确实是非法的，内核就无法从失效地址上“换页”；如果此时处
理在超级用户太，系统于是就产生一个“oops”。值得注意的是，在版本2.1中内核
处理失效的方式有所变化，它可以处理在超级用户态的非法地址引用了。新实现将
在第17章“最近发展”的“处理内核空间失效”中介绍。
oops显示故障时的处理器状态，模块CPU寄存器内容，页描述符表的位置，以及其他
似乎不能理解的信息。这些是由失效处理函数（arch/*/kernel/traps.c）中的printk语句产
生的，而且象前面“Printk”一节介绍的那样进行分派。
让我们看看这样一个消息。这里给出的是传统个人电脑（x86平台），运行Linux 2.0或
更新版本的oops――版本1.2的输出稍有不同。
（代码）
上面的消息是在一个有意加入错误的失效模块上运行cat所至。fault.c崩溃如下代码：
（代码）
由于read从它的小缓冲区（faulty_buf）复制数据到用户空间，我们希望读一小块文件
能够工作。然而，每次读出多于1KB的数据会跨越页面边界，如果访问了非法页面read
就会失败。事实上，前面给出的oops是在请求一个4KB大小的read时发生的，这条消
息在/var/log/messages（syslogd默认存放内核消息的文件）的oops消息前给出了：
（代码）
同样的cat命令却不能在Alpha上产生oops，这是因为从faulty_buf读取4KB字节没有超出页
边界（Alpha上的页面大小是8KB，缓冲区正好在页面的起始位置附近）。如果在你
的系统上读取faulty没有产生oops，试试wc，或者给dd显式地指定块大小。
使用ksymoops
oops消息的最大问题就是十六进制数值对于程序员来说没什么意义；需要将它们解
析为符号。
内核[url=http://www.pccode.net].net" class="wordstyle"源码通过其所包含的ksymoops工具帮助开发人员――但是注意，版本1.2的[1] [url=http://www.chinamx.com.cn/Article/os/Linux/200605/20060530123528_28446_2.html][2] [3] 下一页
