构件化驱动程序模型.docVIP

构件化驱动程序模型 杜永文，何华灿 (西北工业大学计算机科学与工程系，710072) 陈榕 (北京科泰世纪有限公司，100029) 摘 要： 本文首先分析了传统的UNIX操作系统驱动程序模型，指出其存在的局限性；其次介绍了构件技术，并将构件技术运用到设备驱动程序设计中，提出了构件化驱动程序模型，，，Abstract In this paper, we analysis the traditional device driver model in UNIX operating system and point out pitfalls existing in this model. Then we propose component-based device driver model, that make it possible to clearly descript and easily access device. Finally, a mouse driver will be presented to exhibit component-based device driver model. Keywords component technique, device driver model, component object model 1 引言 硬件设备是操作系统管理的重要资源，而设备驱动程序则是使用软件方法访问和操作硬件设备的重要环节，因此驱动程序以及相关的模块就成为系统程序的必要组成部分。 设备驱动程序作为系统程序的一部分，实际上它是一组数据结构和函数，这些数据结构和函数通过精心定义的接口，控制一个或多个设备，并与系统的其它部分交互。 在UNIX系统中设备驱动是内核的一部分，实际上，设备驱动程序是否处于内核中，这并非是设备驱动程序的本质特征，许多操作系统可以把设备驱动程序置于核外，作为提供设备服务的服务器。就这点来说，我们考虑的实际上是设备驱动程序模型的问题。 驱动程序模型着眼于a. 设备驱动程序的管理；b. 驱动程序在整个系统框架中位置；c. 用户与驱动程序的交互。就驱动程序本身来说都是受限于以上因素，在以上因素确定的情况下，考虑具体的设备细节，相应的设备驱动程序也就成型了。从b可以看出驱动程序模型是系统框架的一部分，因此讨论驱动程序模型自然要讨论系统框架。本文第二部分会讨论UNIX操作系统的驱动程序模型。 随着嵌入式应用的广泛普及，设备多样化，都使得对于设备驱动程序的研究显得更为重要，模块化、便于升级、稳定性成为设备驱动程序必要的特性，为了适应新的需求，有必要改造驱动程序模型，建立新的驱动程序模型。 纵观以往操作系统中驱动程序的模型，尤其类似UNIX系统中设备驱动程序往往是同文件系统相关联的，用户通过系统提供的统一接口访问硬件设备，这样系统和驱动程序耦合过于紧密，导致驱动程序用户接口不够灵活，关于这点第二部分将着重论述。 第三部分主要介绍构件技术的发展以及现况；第四部分考虑用构件技术重新来构造驱动程序，提出了构件化的驱动程序模型，弥补UINX驱动程序模型的一些缺陷；文章的最后，用新的模型构造鼠标驱动，展示了构件化驱动程序模型。 2 UNIX操作系统的驱动程序模型[1] 图1说明了UNIX系统的设备驱动程序作用和在系统构架中的位置。用户应用程序通过使用系统调用接口进入内核访问I/O子系统，内核的I/O子系统接受这些请求，然后它又利用设备驱动程序接口访问和操作硬件设备。 这整个过程分为几层来实现，每一层有明确定义的环境和职责。用户应用程序不必知道它是在访问设备驱动程序还是普通文件。一个将数据写到文件中的程序就应该能够在不作修改的情况下将同样的数据写到一个终端或串行线上。用户对于驱动程序的访问是通过系统调用陷入到内核中，内核将所有设备操作传递给I/O子系统，由它来负责所有独立于设备的处理。I/O子系统并不关心某个特定设备的特性，它将设备看作设备驱动程序接口处理的高层抽象，其关心的只是访问权限、数据缓冲和设备命名等。 图1 UNIX设备驱动程序作用 UNIX系统中的驱动模型和I/O子系统的的设计实际上是提供了一个一致的、高级的文件视图，所有设备的处理都是文件处理的方式。内核可以对所有设备(更确切地说是一类设备，UNIX中的设备分为块设备、字符设备和网络设备等，它们的设备驱动程序接口有所不同)一视同仁，通过相同的接口访问设备。驱动程序模型和操作系统之间建立了事实上的标准和规范，支持这样的标准和规范系统才能帮助完成驱动程序和应用程序之间的数据交换和信息传递。 驱动程序模型和系统之间的标准和规范就是统一的驱动程序接口，实际上就是设备开关表： bdevsw { int(* d_open ) ();