VxWorks驱动程序开发指南（四）--驱动程序的组织结构

驱动程序的组织结构

驱动程序最重要的部分就是驱动程序源代码文件，源文件描述了设备如何和VxBus、VxWorks OS交互。但是，VxWorks 设备驱动程序还需要另外一些文件，这些附加文件能够帮助你将自己编写的驱动集成到VxWorks编译环境中去，这也是发布驱动程序最重要的一步。本节主要讨论如何在源码树中找到相关的驱动程序文件和其他附加文件。最后还说明驱动程序的各个部分是如何安装在VxWorks OS中的。

3.1 文件位置

在开发驱动程序之前，了解驱动程序文件在VxWorks源码树中的位置是非常重要的，驱动程序文件主要分布在源码树中的3个不同位置。

• installDir/vxworks-6.x/target/3rdparty      第三方提供的基于VxBus驱动模型的驱动，它们一般都做为插件安装到现有的VxWorks开发环境中
• installDir/vxworks-6.x/target/src/hwif       风河官方提供的基于VxBus驱动模型的驱动程序，它们一般都作为标准产品的一部分，或者作为补丁来升级。
• installDir/vxworks-6.x/target/src/drv         风河官方提供的基于传统模型的驱动程序，和VxBus不兼容

3.3.1 风河官方的驱动程序

根据驱动程序的类型，installDir/vxworks-6.x/target/src/hwif目录下的驱动被组织成不同的子目录，例如，定时器的驱动程序在目录installDir/vxworks-6.x/target/src/hwif/timer

3.3.2 第三方的驱动程序

第三方驱动程序的组织方式允许驱动程序开发厂商和开发者创建第三方驱动程序，不需要担心不同厂商的文件之间的命名空间冲突。每一个想提供VxWorks驱动程序的厂商必须在3rdparty目录创建自己的子目录，比如说，Acme公司计划为vxworks开发第三方设备驱动程序，那么就必须在3rdparty目录创建自己的目录installDir/vxworks-6.x/target/3rdparty/acme，在这个目录下，不同类型的驱动程序又组织成不同目录，跟hwif目录一样。

3.2 驱动程序文件例子：wrsample

风河公司提供的VxBus的驱动程序例子位于目录：installDir/vxworks-6.x/target/3rdparty/windriver/wrsample，这些文件可以被当做模板来帮助你开发第三方驱动程序，具体信息请参考wrsample目录下的README文件。

3.3 其他必须的文件

尽管一个驱动程序可以包括很多文件，比如多个源文件和多个头文件，但是一个标准的VxWorks驱动程序有一个最小的文件集，对于大多数vxworks驱动程序最少要求6个文件：

• 驱动程序源文件                       实现驱动程序控制逻辑
• 组件描述文件（CDF）          主要用于将驱动程序集成到VxWorks编译环境中，以便于配置
• 一个driverName.dc文件        提供驱动注册例程的原型
• 一个driverName.dr文件         提供一小段调用驱动注册例程的代码
• README文件                          提供版本信息
• Makefile文件                            提供编译规则

一般情况下，CDF文件，dc文件，dr文件都被认为是驱动程序的配置文件，下面详细介绍这些文件。

3.3.1 驱动程序源文件

驱动程序源文件包含了驱动程序功能的实现逻辑，它们被放在目录installDir/vxworks-6.x/target/src/hwif， 第三方的被放在目录installDir/vxworks-6.x/target/3rdparty。很多VxWorks设备驱动程序只包含一个源文件，一个驱动程序可以包含一个或者几个可选的头文件；但是驱动程序可以包含多个源文件，但是此时必须在Makefile里面提供各个模块的依赖规则。下面以文件vxbCn3xxxTimer.c来说明VxWorks驱动程序的结构。

 

设备驱动程序的第一部分是一个描述VxBus初始化阶段要调用的例程的结构：

/* data structures used by the driver to register itself
* with Vxworks
*/
/* drvBusFuncs provides a set of entry points into the
* driver that are called during various phases of the
* boot process. Drivers can choose to implement 1 or
* more of these entry point, according to the needs of
* the driver during its initialization phases.
*/
LOCAL struct drvBusFuncs cn3xxxTimerDrvFuncs =
{
cn3