一种新型的基于构件和微内核的设备驱动模型

Windows NT / 2000 / XP 中 的 硬 件 驱 动 程 序 按 照 运 行 模 式
的不同分成两类： 一种运行在用户模式， 由于 Windows 2000 不 允许用户模式直接访问硬件， 因此需要实际的硬件驱动上有一 个虚拟的硬件驱动，这和 Windows 9X 系列的 VxD 是一样的； 另一种直接运行在内核模式下。
1
引言
硬件设备是计算机的必要组成， 因此硬件设备驱动程序在
大 部 分 的 Unix ， 以 及 Windows 9x 系 列 [1]， 而比较 核， 如 Linux ， 标准的微内核如 MACH ，核内包括的抽象功能模块只有进程、 线程、 内存对象、 消息和端口。 单体内核中， 驱动程序常驻于内核中， 凭借内核的效率， 对 访问硬件的速度有利， 同时亦影响内核的安全性， 而内核发生 错误将是致命的。微内核中， 驱动模块在核外， 内核安全性加 强， 同时以效率的缺失为代价。 对于微内核与单体内核的争论， 目前仍集中于效率与安全 性这两者的矛盾上， 在一些通用操作系统上， 这两者的界限变 得模糊， 如 Linux 的 驱 动 可 以 自 由 装 入 内 核 或 者 卸 载 ， 但这仍 然局限于源代码的编译阶段。
Windows 系 列 操 作 系 统 下 对 设 备 及 其 驱 动 的 分 类 更 为 细
致， 大体可以划分为用户模式驱动和内核模式两类， 而内核模 式的驱动又分为传统的驱动 （Legacy Drivers， 和 WDM Non-PNP） （Windows 驱 动 模 型 ） 的 PNP 设 备 驱 动 。 其 中 WDM 的 驱 动 可 以在内核中动态加载与卸载。
2
CAR 构件技术
（构件装配运行平台， ： CAR Component AssembIy Runtime ）
CAR 构件技术是科泰公司自主开 发 的 面 向 构 件 编 程 的 编 程 模
型， 其中规定了一组构件间相互调用的标准， 使得二进制构件 能够自描述， 能够在运行时动态链 接 。 CAR 与 微 软 的 COM 能 够二进制兼容， 但禁止用户定 义 非 自 描 述 接 口 ， CAR 完 备 了 构 件及其接口的自描述功能， 实现了 对 COM 的 扩 展 。 CAR 构 件 使用一套类似于 IDL 的语言对构件 接 口 进 行 描 述 ， 描 述 CAR 的文件为 car 文件。 CAR 与 COM 的其他不同之处在于： 运行环境 （context） 的处理上， （l ） COM 将 相 关 运 行 信 息 注 册到注册表中， 而 CAR 自 动 封 装 到 构 件 所 在 的 dII （动 态 连 接 库） 中， dII 导出标准函数调用。 （2 ） 构件的依赖关系， （或 者 COM 构 件 只 有 关 于 自 身 接 口 说功能） 的自描述， 而 CAR 构件中对构件的依赖关系进行封装 （导入信息） 。
摘 要 论文首先从内核性能和安全性的角度分析驱动程序对微内核与单体内核的影响；然后讨论硬件抽象层对驱动
抽象能力的影响以及与移植性及内核大小的关系；分析传统 UNIX 系列与 Windows NT 操作系统内核结构以及驱动模 型优缺点； 最后介绍一个构件化驱动模型的特点。该模型基于构件装配运行平台技术， 运行在和欣 2.0 操作系统平台上。 驱动模型底层是一个合适的硬件抽象层， 方便移植， 用户态程序可以灵活地调用驱动程序。 关键词 微内核 构件技术 驱动模型 文献标识码 A 中图分类号 TP33
3 构件化的硬件驱动模型 3.l 常用操作系统的驱动模型
（l ） UNIX 如 图 l， 内核下面是硬件层， 内核中 UNIX 采 用 单 体 内 核 ， 的设备驱动位于文件系统之下， 所有的设备驱动都被视为一个 或多个文件， 设备驱动通过文件系统向内核顶层的系统调用接 口提供服务， 内核外的应用层通过内核提供的系统调用接口访 问文件系统中的设备驱动， 从而操作硬件。
一种新型的基于构件和微内核的设备驱动模型
郑任持 1 王晨辉 2 陈
3 榕 2，
王小鸽 3
1 （清华大学深圳研究生院软件工程中心， 深圳 518055） 2 （科泰世纪有限公司， 上海 201203） 3 （清华大学信息技术研究院操作系统中心， 北京 100084 ）
E-maiI： zrc02@
计算机工程与应用
2005.7
93
系仍然是静态的。 构件技术基于面向对象技术， 通过构件二进制的封装以及 动态连接技术， 解决诸如动态升级、 动态替换的问题。 构件技术 对一组类进行封装， 完成一个或多个功能的服务， 同时为用户 提供若干个接口。 构件之间使用约定的接口进行数据交换和信 息传递， 构件的位置相互之间透明， 可以做到同进程、 异进程甚 至跨机器的调用。 由于构件有一定的二进制规范， 因此， 可以使 用不同的语言编写构件， 只要符合约定的构件规范即可。 构件通常使用一种与实现语言无关的接口定义语言 （ IDL） 来定义接口。IDL 文件描述了数据类型、 操作和对象， 客户通过 它来构造一个请求， 服务器则为一个指定对象的实现提供这些 数据类型、 操作和对象。 自描述数据是指数据类型自身所带有的数据信息已经足 够描述其自身的特征， 比如占用内存的情况、 它的基本属性及 其它的相关信息等， 也就是说， 不需要其他附加条件也能够实 现自我描述的数据类型。 构件中使用自描述数据是为了在接口 参数的传递中， 简化参数的列集和散集。 论文将介绍一个新型的基于构件技术和微内核技术的设 备驱动模型， 讨论把构件技术引入设备驱动程序的开发的技术 优势， 并给出在国产的和欣操作系统上实现一个构件化基础的 设备驱动模型的实例， 以期在硬件驱动性能与内核安全性的矛 盾之间寻求一个合理的平衡点， 并且利于针对硬件的高层应用 开发的需求。
图l
UNIX 内核结构
统一的文件式设备接口给管理和访问设备带来方便的同 时， 也带来问题： 一些硬件内部的细节特性无法通过这种统一 的接口体现出来， 比如打印机与鼠标同属于字符设备， 它们的 具体调用特性却不能从字符设备开关表中获得。 （2 ） Windows 图 2 中， Windows NT / 2K 系 列 的 操 作 系 统 的 内 核 模 式 是 存在争议的微内核， 分成用户层 （User Mode ） 和内核层 （KerneI 两种模块， 在 内 核 底 层 提 供 了 一 个 HAL （硬 件 抽 象 层 ， Mode ） ， Hardware Abstraction Layer） HAL 对 内 核 上 层 的 IO 管 理 器 、 设备驱动提供抽象的硬件访问服务， 内核对用户层提供可执行 组件、 设备驱动和其他 的 内 核 模 块 也 可 IO 管理等接口。然而， 以绕过 HAL 访问底层硬件。
Abstract： First， this paper anaIyses how micro kerneI and monoIithic kerneI infIuence device drivers in the aspects of kerneI performance and security.Second， it discusses the reIationship among hardware abstraction Iayer and drivers' abstraction， portabiIity and the size of the kerneI， anaIyses the UNIX series and Windows NT operating system， and summarizes specification of their kerneI architecture and device drivers st， it deveIops a driver modeI based on component.The driver modeI runs in EIastos OS with a proper hardware abstraction Iayer， and the user-mode program can caII the drivers easiIy and agiIeIy. Keywords： micro kerneI， component technoIogy ， driver modeI
操作系统中也是重要的成分， 在操作系统中， 硬件驱动模型决 定了硬件驱动程序的管理方式和访问方式。 这两者关系到操作 系统能否合理发挥硬件设备的功能、 协调系统性能以及应用程 序如何调用驱动。
1.1
内核
内核是操作系统最核心的组成部分， 虽然操作系统高层特
性与内核之间的耦合日趋缩小， 但内核结构仍然是操作系统常 用的分类标准。操作系统按照内核结构可大致分为单体内核 与微内核 （micro kerneI） 。 （monoIithic kerneI） 单体内核将操作系统中的图形系统、 设备驱动、 文件系统 等全部功能性部件在操作系统内核中实现，运行在内核状态、 同一地址空间， 使之成为一个单体， 而微内核则强调结构性部 件与功能性部件的分离， 核内一般只包括进程 管 理 、 I / O 处理、 内存管理、 进程间通讯等。一般传统的操作系统都属于单体内
（2005 ） 文章编号 1002-833107-0093-04
A New Driver Model Based on Component and Micro-kernel
3 Zheng Renchi1 Wang Chenhui2 Chen Rong2， Wang Xiaoge3 1 （ Software Engineering Center ， Graduate SchooI at Shenzhen ， Tsinghua University， Shenzhen 518055） 2 （Shanghai Koretide Corporation ， Shanghai 201203） 3 （Operating System Center ， Research Institute of Information TechnoIogy of Tsinghua University ， Beijing 100084）