分类：
2008-04-08 17:10:53
在创建新驱动程序软件时请遵循以下准则：
使用基于驱动程序名的前缀来指定全局变量和函数的惟一名称。
如果开发基于现有的驱动程序，则在添加驱动程序前请修改配置文件。
利用 命令中的 -n 选项，可以在不加载或连接驱动程序的情况下更新驱动程序系统的配置文件。
使用 cmn_err() 函数而不使用 printf() 来记录驱动程序活动。
函数是在控制台上显示信息的推荐方法。对于显示诸如设备注册位之类的驱动程序所使用的专用格式，与 相比，该函数具有更多的功能和用途。
驱动程序退出时清除分配和其他初始化活动。
驱动程序退出时，无论是有意的还是无意的，都需要执行诸如关闭已打开的文件、释放已分配的内存、解除互斥锁和删除已创建的所有互斥之类的任务。此外，系统必须能够关闭所有的次要设备并分离驱动程序实例，即使是在硬件出现故障以后。正确的操作顺序为：反转_fini() 例程中的 _init()操作，反转 close() 例程中的 open()操作，以及反转 detach() 例程中的 attach()操作。
使用 来捕捉意外的出错返回。
ASSERT() 是一个宏，它在预期为真的条件结果却为伪情况下异常终止内核执行。要启用 ASSERT()，需要在编译期间包含 sys/debug.h 头文件并指定 DEBUG 预处理程序符号。
使用 mutex_owned() 验证加锁要求和编制相关文档。
函数可帮助确定当前线程是否拥有指定的互斥。要确定线程是否拥有互斥，请在 ASSERT() 内部使用 mutex_owned()。
使用条件编译来减轻调试工作的压力。
Solaris 操作系统提供多种调试函数，如 assert() 和 mutex-owned()，它们可以在编译驱动程序时通过指定 DEBUG 预处理程序符号来启用。借助条件编译，多余代码可以从生产驱动程序中删除。该方法也只可以通过使用全局变量来实现。
将一个单独的驱动程序实例用于每个要控制的设备。
在设备驱动程序中尽可能多地使用 DDI 函数。
这些接口消除了驱动程序对不同平台的依赖性，如处理器和设备字节顺序之间的不匹配以及其他的数据命令相关性。借助这些接口，单一来源的驱动程序可以运行在 SPARC 平台、x86 平台和相关的处理器架构上。
预测损坏的数据。
在使用数据前要先检查数据完整性。驱动程序必须避免将错误数据释放到系统的其他部分。
设备应当只向只受控于该驱动程序的 DMA 缓冲区写入数据。
这种方法可以防止 DMA 故障破坏系统主内存的任意部分。
需要进行 DMA 传输时使用 函数。
该函数可保证只传输已调整的完整页面。
在采取备用措施以处理经常性的中断之前，设置固定数量的尝试。
如果设备加了锁，设备驱动程序不可以无限制地消耗系统资源。如果设备总是忙，则驱动程序应该是超时了。驱动程序还应检测经常性的中断请求并采取适当措施。
在设置互斥获得与解除时要小心，以避免设备出现故障时不必要的线程交互。
请参阅，了解更多信息。
检查来自用户应用程序的异常 ioctl() 请求。
用户请求可能会有潜在和有意的破坏性。驱动程序的设计应考虑到每种类型潜在 ioctl() 请求的构造。
要设法避免驱动程序仍在继续运行却不检测设备故障的情况发生。
某一驱动程序应切换到备用设备，不应一味地处理设备故障。
Solaris 操作系统中的所有设备驱动程序都必须支持热插拔。
所有设备都要能够在不重启系统的情况下安装或删除。
所有设备驱动程序都应支持电源管理。
电源管理提供了控制和管理计算机系统或设备的电能使用的能力。通过在空闲时减少电能消耗以及在不使用时完全切断电源，电源管理使系统能够节省能源。
将 volatile 关键字应用于引用了设备寄存器的任何变量。
若不带 volatile 关键字，编译时优化器可能会删除对寄存器的重要访问。
执行定期的状况检查以检测和报告有故障的设备。
定期的状况检查应包括下列活动：
检查设备上所有的寄存器或存储单元，它们的值自最后一次轮询以来可能已经改变了。
时间戳传出请求，如驱动程序发出的发送块或命令。
在设备上启动一个应在计划的下一次检查之前完成的测试。
