其他编程注意事项

除了前面各节中讨论的要求外，还请考虑以下问题：

• 线程交互

• 自上而下请求的威胁

• 自适应策略

线程交互

设备驱动程序中内核出现紧急情况通常是由设备发生故障后内核线程的意外交互引起的。设备出现故障时，线程可能会以您意想不到的方式进行交互。

如果处理例程较早终止，则条件变量等待程序将由于从未给定预期信号而被阻塞。尝试向其他模块通知故障或处理意外回调会导致不需要的线程交互。请考虑设备发生故障期间获取和释放互斥锁的顺序。

如果源自上游 STREAMS 模块的线程被用来意外返回该模块，则这些线程可能得出自相矛盾的结果。请考虑使用备用线程来处理异常消息。例如，过程可以使用读端服务例程与 M_ERROR 进行通信，而不直接使用读端 putnext(9F) 处理错误。

在关闭期间由于故障而无法处于静态的发生故障的 STREAMS 设备会在流终止后生成中断。中断处理程序不得尝试使用过时的流指针来处理消息。

自上而下请求的威胁

针对有缺陷的硬件为系统提供保护的同时，您还需要针对驱动程序误用提供保护。尽管驱动程序可以假定内核基础结构始终正确（受信任的核心），但传递给它的用户请求可能具有破坏性。

例如，用户可以请求对用户提供的数据块 (M_IOCTL) 执行某一操作，该数据块小于消息的控制部分所指示的块大小。驱动程序绝不应该信任用户应用程序。

请考虑您的驱动程序可以接收的每种类型的 ioctl 的构造以及 ioctl 可能引起的潜在危害。驱动程序应执行检查，以确保它不处理格式错误的 ioctl。

自适应策略

驱动程序可以使用有故障的硬件继续提供服务。驱动程序可以尝试使用用于访问设备的备用策略来解决已确定的问题。假定损坏的硬件不可预测并且已知与其他设计复杂性关联的风险，则自适应策略并不总是明智的选择。这些策略最多应限制为定期中断轮询和重试尝试。定期重试设备可使驱动程序了解设备恢复的时间。强制驱动程序禁用中断后，定期轮询可以控制中断机制。

理论上，系统始终有一个备用设备来提供重要的系统服务。内核或用户空间中的服务多路复用程序可在设备出现时提供维护系统服务的最佳方法。此类做法将不在本节中进行介绍。