Linux内核调试（2） 配置文件, 缓冲区, Linux, 记录, 空间

yuyang911220

3、记录缓冲区
   内核消息都被保存在一个LOG_BUF_LEN大小的环形队列中。
   关于LOG_BUF_LEN定义：
   #define __LOG_BUF_LEN     (1 << CONFIG_LOG_BUF_SHIFT)
   ※ 变量CONFIG_LOG_BUF_SHIFT在内核编译时由配置文件定义，对于i386平台，其值定义如下（在linux26/arch/i386/defconfig中）：
   CONFIG_LOG_BUF_SHIFT=18

   记录缓冲区操作：
   ①、消息被读出到用户空间时，此消息就会从环形队列中删除。
   ②、当消息缓冲区满时，如果再有printk()调用时，新消息将覆盖队列中的老消息。
   ③、在读写环形队列时，同步问题很容易得到解决。
   ※ 这个纪录缓冲区之所以称为环形，是因为它的读写都是按照环形队列的方式进行操作的。

4、syslogd和klogd
   在标准的Linux系统上，用户空间的守护进程klogd从纪录缓冲区中获取内核消息，再通过syslogd守护进程把这些消息保存在系统日志文件中。klogd进程既可以从/proc/kmsg文件中，也可以通过syslog()系统调用读取这些消息。默认情况下，它选择读取/proc方式实现。klogd守护进程在消息缓冲区有新的消息之前，一直处于阻塞状态。一旦有新的内核消息，klogd被唤醒，读出内核消息并进行处理。默认情况下，处理例程就是把内核消息传给syslogd守护进程。
   syslogd守护进程一般把接收到的消息写入/var/log/messages文件中。不过，还是可以通过/etc/syslog.conf文件来进行配置，可以选择其他的输出文件。
  图1 X光了此过程：
  
  
四、OOPS
OOPS（也称 Panic）消息包含系统错误的细节，如 CPU 寄存器的内容等。是内核告知用户有不幸发生的最常用的方式。
内核只能发布OOPS，这个过程包括向终端上输出错误消息，输出寄存器保存的信息，并输出可供跟踪的回溯线索。通常，发送完OOPS之后，内核会处于一种不稳定的状态。
OOPS的产生有很多可能原因，其中包括内存访问越界或非法的指令等。
※ 作为内核的开发者，必定将会经常处理OOPS。
※ OOPS中包含的重要信息，对所有体系结构的机器都是完全相同的：寄存器上下文和回溯线索（回溯线索显示了导致错误发生的函数调用链）。

1、ksymoops
    在 Linux 中，调试系统崩溃的传统方法是分析在发生崩溃时发送到系统控制台的 Oops 消息。一旦您掌握了细节，就可以将消息发送到 ksymoops 实用程序，它将试图将代码转换为指令并将堆栈值映射到内核符号。
    ※ 如：回溯线索中的地址，会通过ksymoops转化成名称可见的函数名。
    图2X光了格式化 Oops 消息过程：
   
  
    ksymoops需要几项内容：Oops 消息输出、来自正在运行的内核的 System.map 文件，还有 /proc/ksyms、vmlinux 和 /proc/modules。
关于如何使用 ksymoops，内核源代码 /usr/src/linux/Documentation/oops-tracing.txt 中或 ksymoops 手册页上有完整的说明可以参考。Ksymoops 反汇编代码部分，指出发生错误的指令，并显示一个跟踪部分表明代码如何被调用。

2、kallsyms
    开发版2.5内核引入了kallsyms特性，它可以通过定义CONFIG_KALLSYMS编译选项启用。该选项可以载入内核镜像所对应的内存地址的符号名称（即函数名），所以内核可以打印解码之后的跟踪线索。相应，解码OOPS也不再需要System.map和ksymoops工具了。另外，
这样做，会使内核变大些，因为地址对应符号名称必须始终驻留在内核所在内存上。
    #cat /proc/kallsyms
     c0100240   T       _stext
     c0100240   t       run_init_process
     c0100240   T      stext
     c0100269   t       init