嵌入式Linux Kernel错误跟踪技术
这种解决问题所需时间呈上升的趋势固然有软件问题，但缺乏必要的手段以辅助解决问题才是主要的原因。通过对故障的统计跟踪发现，难以解决的软件错误和从发现到解决耗时较长的软件错误都集中在操作系统的核心部分，这其中又有很大比例集中在驱动程序部分[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内核对异常情况的处理流程。
评论