嵌入式Linux Kernel错误跟踪技术

随着嵌入式Linux系统的广泛应用，对系统的可靠性提出了更高的要求，尤其是涉及到生命财产等重要领域，要求系统达到安全完整性等级3级以上[1]，故障率（每小时出现危险故障的可能性）为10-7以下，相当于系统的平均故障间隔时间（MTBF）至少要达到1141年以上，因此提高系统可靠性已成为一项艰巨的任务。对某公司在工业领域14 878个控制器系统的应用调查表明，从2004年初到2007年9月底，随着硬软件的不断改进，根据错误报告统计的故障率已降低到2004年的五分之一以下，但查找错误的时间却增加到原来的3倍以上。

这种解决问题所需时间呈上升的趋势固然有软件问题，但缺乏必要的手段以辅助解决问题才是主要的原因。通过对故障的统计跟踪发现，难以解决的软件错误和从发现到解决耗时较长的软件错误都集中在操作系统的核心部分，这其中又有很大比例集中在驱动程序部分[2]。因此，错误跟踪技术被看成是提高系统安全完整性等级的一个重要措施[1]，大多数现代操作系统均为发展提供了操作系统内核“崩溃转储”机制，即在软件系统宕机时，将内存内容保存到磁盘[3]，或者通过网络发送到故障服务器[3]，或者直接启动内核调试器[4]等，以供事后分析改进。

基于Linux操作系统内核的崩溃转储机制近年来有以下几种：

(1) LKCD（Linux Kernel Crash Dump）机制[3];

(2) KDUMP（Linux Kernel Dump）机制[4]；

(3) KDB机制[5]；

(4) KGDB机制[6]。

综合上述几种机制可以发现,这四种机制之间有以下三个共同点：

(1) 适用于为运算资源丰富、存储空间充足的应用场合；

(2) 发生系统崩溃后恢复时间无严格要求；

(3) 主要针对较通用的硬件平台，如X86平台。

在嵌入式应用场合想要直接使用上列机制中的某一种，却遇到以下三个难点无法解决：

(1) 存储空间不足

嵌入式系统一般采用Flash作为存储器，而Flash容量有限，且可能远远小于嵌入式系统中的内存容量。因此将全部内存内容保存到Flash不可行。

(2) 记录时间要求尽量短

嵌入式系统一般有复位响应时间尽量短的要求，有的嵌入式操作系统复位重启时间不超过2s，而上述几种可用于Linux系统的内核崩溃转储机制耗时均不可能在30s内。写Flash的操作也很耗时间，实验显示，写2MB数据到Flash耗时达到400ms之多。

(3) 要求能够支持特定的硬件平台

嵌入式系统的硬件多种多样，上面提到的四种机制均是针对X86平台提供了较好的支持，而对于其他体系的硬件支持均不成熟。

由于这些难点的存在，要将上述四种内核崩溃转储机制中的一种移植到特定的嵌入式应用平台是十分困难的。因此，针对上述嵌入式系统的三个特点，本文介绍一种基于特定平台的嵌入式Linux内核崩溃信息记录机制LCRT(Linux Crash Record and Trace)，为定位嵌入式Linux系统中软件故障和解决软件故障提供辅助手段。

1 Linux内核崩溃的分析

分析Linux内核对于运行期间各种“陷阱”的处理可以得知，Linux内核对于应用程序导致的错误可以予以监控，在应用程序发生除零、内存访问越界、缓冲区溢出等错误时，Linux内核的异常处理例程可以对这些由应用程序引起的异常情况予以处理。当应用程序产生不可恢复的错误时，Linux内核可以仅仅终止产生错误的应用程序，其他应用程序仍然可以正常运行。

如果Linux内核本身或者新开发的Linux内核模块存在bug，产生了“除零”，“内存访问越界”、“缓冲区溢出”等错误，同样会由Linux内核的异常处理例程来处理。Linux内核通过在异常处理程序中判断，如果发现是“严重的不可恢复”的内核异常，则会导致“内核恐慌”（kernel panic），即Linux内核崩溃。图1所示为Linux内核对异常情况的处理流程。

2 LCRT机制的设计与实现

通过对Linux内核代码的分析可知，Linux内核本身提供了一种“内核通知机制”[7-8]，并预定义了“内核事件通知链”，使得Linux内核扩展开发人员可以通过这些预定义的内核事件通知链在特定的内核事件发生时执行附加的处理流程。通过对Linux内核源代码的研究发现，对于上文中提到的“严重不可恢复的内核异常”，预定义了一个通知链和通知点，使得在发生Linux内核崩溃之后，可以在Linux内核的panic函数中预定义的一个“内核崩溃通知链”[7]上挂接LCRT机制来获得Linux内核崩溃现场的一些信息并记录到非易失性存储器中，以便分析引起Linux内核崩溃的原因。

2.1 设计要点

LCRT机制的设计和实现基于如下特定的机制：

(1) 编译器选项与内核依赖