Windows CE系统级日志设计

我的经验，可靠的产品不是设计出来的，而是通过持续的解决BUG逐步达到的，当然我不是说设计不重要，我是想强调在产品中提供一些能够帮助诊断问题的设施 是非常有必要的。在这方面，最常见的手段显然就是系统日志了。嵌入式系统由定制的硬件平台、定制的驱动程序、定制的系统组件，以及定制的应用程序构成。这 么多定制的组件凑在一起，要在一个比较短的时间内把他们凑在一起，配合良好顺利运行不容易。他们中的任何部分都有可能出问题，因此应用程序级别的日志模块 显然不足以记录足够的信息，我们需要系统级的解决方案。在Windows CE平台，最有用的日志毫无疑问应该是CE内置的串口输出的调试信息，它的最大优点就是基本上CE平台的所有模块，从boot loader到OAL，从driver到application，都支持并且都能很容易的支持往串口输出调试信息。基本上你要让我诊断一个windows CE问题，我首先想知道的就是你有没有串口输出的调试信息，如果有，问题可能呢就解决了一半。但是在实际的使用中，要得到出问题时的串口输出又是很困难 的，这是因为：1，有些设备可能根本就没有提供串口；2，很少有人在使用设备时还接着跟串口线到电脑上，并且开着HypterTerminal；3，有些 错误不容易重现，即使你的设备有串口输出，你也有串口线，还有电脑可接，但是你已经没法重现错误了。
这篇文章我想谈谈怎么做一个系统级的日志模块，可以把往串口输出的所有调试信息捕捉到日志文件中。这听起来好像不难做到，基本上你要做的是在BSP中重写 OEMWriteDebugString()，把原本往串口输出的字符串重定向到文件中。没错，本质上说起来也就是这么回事，但是要做到这一点，有很多技 术上的问题必须要考虑到。主要的难点有两点：
1，日志文件的存储牵扯到文件系统。这就带来三个问题，一是文件系统只有在kernel启动后并且文 件系统相关的驱动程序加载以后才能访问。在boot loader引导阶段，以及kernel初始化阶段，文件系统是不能用的，日志的存储怎么解决？二是对文件的写操作一般速度比较慢，对系统性能有严重影 响。三是文件存取依赖于文件系统的驱动程序栈（包括文件系统驱动、分区管理驱动、块设备驱动），还涉及到进程/线程间的上下文切换，这相比起串口输出来说 复杂度提高了不止一个数量级，因此可靠性大大降低。
2，系统中的任何模块在任何状态下都可能输出调试信息。什么意思？这意味着：一，你要非常小 心，不能让一个模块的输出block掉另一个模块的输出，输出时的同步锁是必须的，但是锁定状态下的代码必须非常可靠且快速。二，有些输出非常特别，比如 说从中断处理