关键词 ： 构件化驱动 , 构件技术 , 操作系统体系结构
1 操作系统体系结构的争论一般而言操作系统提供两种功能 [2] ：⒈有系统地在互相竞争的进程之间分配计算机资源；⒉作为计算机的扩展，提供功能强大的编程环境和应用环境。由于计算机硬件的快速发展和用户要求的提高，操作系统的复杂性与日俱增，系统的体系结构对系统性能的影响也越来越明显。
关于操作系统体系结构的讨论一直没有停息过，大多数的操作系统采用两种体系结构之一：一个是整体内核 (Monolithic kernel or Macro-kernel) 操作系统，另一个是微内核 (Micro-kernel) 操作系统。
1.1 整体内核操作系统整体内核操作系统有如下特征：操作系统功能定义模块，系统服务和驱动程序都在内核空间，分别定义成不同的功能模块；任何模块可以遵循特定的接口规范来调用其它模块；所有模块必须连接在一起，形成一个可执行文件，使用时整个文件都应完整装载到计算机的内存中；所有模块都运行于超级用户的模式下，可直接取用计算机的硬件资源；应用程序若要取用这种资源，如扫描仪，它需要执行系统调用，请求一个系统模块帮它获取相应的资源。这里的系统调用实际上是这样做的：首先将计算机切换到超级用户模式，然后进入操作系统的某个模块。传统的操作系统都是整体内核的，例如 Microsoft DOS ， Linux ， Unix ， Windows95 等。
1.2 微内核操作系统 [5]微内核是从功能上说，它由操作系统最基础的抽象模块构成的，整体内核系统中包含的许多系统服务以及驱动程序都被放在了核外，核内一般只包括进程管理、 I/O 处理、内存管理、进程间通讯等。 MACH 是非常典型的微内核系统， MACH 的核内包括的抽象功能模块有任务，线程，内存对象，消息和端口，它们提供了管理和处理虚拟内存，调度和进程间通信的机制。模块化的特点使 MACH 拥有可裁剪性，可扩展性，可移植性等良好特性，而这些特性是整体内核操作系统很难具备的。除了 MACH 之外，微内核操作系统还有 QNX 、 MINIX 、 CHORUS 、 AMORBA 等。
2 微内核系统和整体内核系统的比较简而言之，微内核将操作系统的许多服务移到了用户空间，而传统的操作系统通常是将其放在核内的，这对系统的性能产生了显著的影响。微内核系统和整体内核系统比较具有以下优点：
鲁棒性 (Robustness) 微内核系统将许多系统服务放到用户空间，由于这些服务程序是运行在完全独立的内存空间中 ( 当然这里不包括内核级的服务程序 ) ，程序本身存在的 BUG 和不可预知的错误就不会那么容易导致内核的崩溃。
安全性 (Security) 微内核系统的许多模块独立地运行于核外，因此可以以模块为单位把安全问题分解，使得系统服务程序严格按照安全要求运行，而不是“随心所欲”。
可配置性 (Configurability) 一般微内核系统中的服务程序可以在整个系统不重新启动的情况下被更换，这一点对于整体内核的操作系统是难以实现的。
易于编程 内核中的代码通常需要使用特殊的内存分配和输入输出等例行程序，用户态的代码要比核态的代码容易编写，它无须去考虑内核特定的一些限制。
降低内存的固定使用量 分配给内核的内存 ( 代码和数据 ) 一般地说必须驻留在内存中，不允许被交换出内存。被移到用户空间的核态代码越多，内核常驻内存的程序量就越少，移到核外的系统服务程序只有在被用到时才会装入内存。
实时性能 系统运行于核态时，为了防止打断一些临界处理，会暂时禁止中断。内核中的代码越少，禁止中断的机会就越少。
可扩展性 (extensibility) 在微内核系统中添加系统模块就像编写用户程序一样简单，只要它遵从系统提供的设计接口，而整体内核系统添加模块首先需要你对操作系统内部工作机制有一定的了解，在编写好模块程序之后，还需要重新编译内核，以便把添加的模块连接到内核中去。
前面提到的都是微内核系统的进步之处，当然微内核系统也并非完美无缺，微内核系统和整体内核系统相比也有不足之处：
微内核规模并不小 大多数微内核系统的内核规模并不小，尽管“微内核”的名字让人产生这种错觉。 QNX 操作系统是一个例外，如果内核做得很大相应系统的 RAM 使用量就会有所增长；
效率的缺失 将许多系统的服务置于核外，就需要给这些服务程序之间提供相应形式化的消息传递机制 (Message Passing Interface or Remote Procedure Call) 。在整体内核操作系统中，不同的系统服务模块总是通过系统内存来互相传递信息，而微内核结构中就只有用正式的机制，这样会导致性能的降低，在 Linus 和 Tanenbaum 的有名的那场关于微内核与整体内核的争论 [3] 了这个问题；
出现的新问题 系统的部件之间会出现一些新类型的死锁或其他的条件错误，而这些在整体内核的系统中是不会出现的。
3 研究现状由于操作系统体系结构争论的广泛性，大多数从事操作系统研究和实现的学者们都意识到无论整体内核还是微内核结构都不是尽善尽美的。这场争论带来的另一积极后果是，双方的支持者都试图有所改变，以弥补自身系统存在的缺陷。
一直以来，微内核结构的支持者对整体内核系统的可移植性都存在质疑，整体内核的操作系统也尽量使其内核模块化，减少模块之间的依赖性，这样就提高了系统的可维护性和系统的可移植性。
整体内核的支持者对微内核结构最有力的反击往往是效率问题，的确由于微内核系统将很多系统服务放在核外，系统的效率难免会受影响。因此最近几年微内核的支持者忙于研究如何提高系统的效率，一种途径是寻找更优的进程间通讯机制，以便从根本上提高效率，另一种结果是一些微内核系统把有的系统服务又重新置于内核之中，这从某种程度上确实提高了效率，但是其代价是一定程度上违背了微内核的初衷。
近几年由于嵌入式系统的飞快发展，微内核操作系统的研究又成为热点，这主要是因为嵌入式系统资源有限，而整体内核系统的内核一般都要占据很大的内存空间，这是嵌入式系统无法容忍的。嵌入式系统看好微内核的另一重要原因是鲁棒性和可动态配置，因为许多嵌入式系统应用是用于控制系统，控制失灵往往会造成难以估计的灾难。微内核的缺点在嵌入式系统的应用中仍然非常突出，嵌入式系统通常都要求较高的效率。
从上面的论述中可以看出，微内核和整体内核的争论问题，最后归结为稳定性和效率的选择问题。迄今为止，仍没有很完美的解决方案，一般是根据问题的重点决定采用某种方案。
4 和欣操作系统和欣操作系统 [1] 是北京科泰公司自行研制开发的一个基于构件化软件模型的系统，适应嵌入式实时需求，基于灵活内核技术，直接支持浏览器，对网络应用可提供强大支持。它具有许多先进的特性，在这里我们主要关注和构件化驱动程模型紧密相关的特性。
首先，和欣是基于构件化软件模型的操作系统。构件化软件设计思想贯穿了整个系统的设计与实现中，系统实现本身就是构件模式。除微内核中最底层的控制部分外，所有系统功能都是以构件接口的形式提供。另外，操作系统对构件化软件模型提供了必要的运行环境，来源不同的构件可以在该环境上实现互操作。系统提供了构件自动寻址 / 自动加载机制，用户不必知道调用的构件程序是本地的还是来自于网上，也就是说，构件运行环境可以对用户透明。构件化系统的实现，使得操作系统本身具有高度的灵活性和扩展性。和欣采用的构件技术是 ezCOM 技术，该技术是北京科泰公司开发的一项技术，它基于微软的 COM 技术，后面会详细介绍 ezCOM 技术。
其次，和欣系统实现了灵活内核技术（ Agile Kernel ）。 用户可以根据需要，将一些来源值得信赖或对运行效率要求高的驱动程序配置于内核态，而另一些置于用户态，在一个嵌入式系统中同时满足安全性与实时性的特殊要求。构件、中间件技术提供了一致性的构件加载规范，不同的就是让调用的构件运行在内核空间还是用户空间。在这样的体系结构中，我们不必区分是大内核还是微内核，事实上，所谓的 “ 内核 ” 可大可小，完全依据系统自身的需求动态决定。
图 1 和欣的灵活内核技术
5 ezCOM 技术80 年代以来，面向对象型软件编程技术有了很大的发展，为大规模的软件协同开发以及软件标准化、软件共享、软件运行安全机制等提供了理论基础。实际上，面向对象技术的发展一直是为了解决软件工程提出的问题。
在过去二十年里，软件工程出现了许多需要解决的问题是： 1. 面向对象软件的封装技术。这就是将复杂的问题，通过封装变成许多相对简单、独立的问题； 2. 软件模块之间的互操作性； 3. 软件版本升级的独立性。任何一个构件的升级或变化都不会影响到系统中与其进行互操作的其他构件； 4. 构件实现的语言无关性； 5. 运行环境的透明性。需要一个简单、统一的编程模型，使得构件可以在进程内、跨进程甚至于跨网络运行。同时提供系统运行的安全、保护机制。
在各个时期为了解决这些问题，软件技术经历了几个发展阶段。以 C++ 为代表的面向对象的编程技术从源程序级实现了对象封装，但它的模块之间是静态绑定； COM 程序模型 [4] 采用了构件化技术，它主要强调构件之间的相互操作的协议标准，模块之间是动态绑定的； COM+ 程序模型实现了中间件技术，也就是在服务与客户之间动态添加中间层，在中间层可以完成与服务逻辑上正交的一些事务处理，如安全事务处理、网络负载均衡等。
从 C++ 到 COM 、 COM+ ，软件工程技术的发展使人们更加深入地认识了科学的编程方法学，同时也为解决本节开头提出的软件工程问题提出了更加完美的解决方案。
和欣操作系统采用了构件技术框架， ezCOM 技术 [1] 就是该框架的核心内容。它基于成熟的 COM 技术，并对该技术作了一些重要的发展， ezCOM 技术具有以下特点：
灵活的实现机制 提供了优化、方便的 ezCOM 工具库和 ezCOM 库支持环境，灵活的 ezCOM 服务器和 ezCOM 客户的实现机制。
简化的构件封装技术 ezCOM 客户和所使用的 ezCOM 构件对象之间增加了由 ezCOM 工具库自动实现的封装层，屏蔽了调用 COM 构件对象过程的繁琐细节，大大简化了 COM 客户的实现。
图 2 ezCOM 运行机制
增加了标准接口的实现类来完成标准接口的实现 该标准接口类的实现可以由 ezCOM 工具库自动完成，开发者在实现 ezCOM 构件类时，只要它继承了标准接口实现类就不用再关心标准接口的实现，但这丝毫不会改变接口二进制接口标准。
统一的类厂实现
扩展的接口描述语言 为 ezCOM 服务器中新功能的实现提供了方便，如脚本语言调用构件对象函数等。
和欣操作系统的基本系统服务均使用 ezCOM 技术包装，而且在核心态与用户态统一系统服务的接口，这一点显然不同于以往的许多操作系统。以往的多数操作系统提供两份功能相似的系统服务接口，其中一份给内核模块使用，另一份给用户态模块使用。和欣系统的这一特性使得编写既能运行于核内又能运行于核外的功能模块成为可能。
图 2 展示了和欣操作系统中 ezCOM 技术的运行机制。当用户程序调用一个构件时，系统便根据构件的元数据创建一个代理构件，用户程序通过代理构件实现对构件对象的访问。图中虚线框中的部分是系统自动生成的构件运行环境。系统通过对代理构件的管理实现 ezCOM 的种种特性。
6 构件化驱动程序设计自从关于微内核和整体内核的争论开始以来，双方的支持者都在不同的程度上对各自的体系结构进行了改造，但矛盾依然存在。下面提出的基于和欣操作系统的构件化驱动程序模型将尝试解决这一矛盾，确切地说解决途径是在微内核系统和整体内核系统之间寻求一种折衷方案。
构件化驱动程序设计方案是使用 ezCOM 构件技术封装驱动程序，每个驱动程序都是一个模块化非常强的构件。这些构件由 DLL 的形式承载，一个 DLL 中可以封装一个或多个驱动程序构件。使用 ezCOM 构件技术封装驱动程序使得驱动程序可继承 ezCOM 的大部分优点，而且也给驱动程序带来了新的特性。构件化驱动程序可以建立符合设备功能和用户理解的接口，这一点不同于类 UINX 系统， UINX 系统的驱动程序都是以文件的接口形式体现。
由 ezCOM 技术封装的驱动程序根据功能区分将提供两组接口，一组为系统功能接口；另一组为用户使用接口。系统功能接口是用于从系统角度管理设备驱动程序，完成设备驱动的配置、初始化和启动终止等功能。用户使用接口是用户程序（驱动程序的客户端程序）使用，通过这些接口用户程序可以访问改程序驱动的硬件设备，实现和硬件设备的信息交换。
构建设备驱动程序的代码只会使用内核提供的基本系统服务或由这些基本系统服务构建的服务模块，基于这一原则构建的设备驱动程序可以灵活地选择运行环境。具体地说，设备驱动程序可以动态配置到以下几种环境中运行： 1. 在系统内核中运行驱动程序； 2. 在用户进程内运行驱动程序； 3. 在内核外地进程外服务模块运行驱动程序。和欣操作系统的统一系统服务接口和 ezCOM 技术提供的灵活的跨边界构件运行机制保证了构件化设备驱动程序的以上三种运行方式。在图 1 中也可以看到这一点。
通过动态配置驱动程序的运行环境，和欣操作系统能够在多种系统性能之间进行选择。如果某一个驱动程序经过长期测试具有很强的稳定性或是系统追求高效率时，可以让驱动程序在核内运行，这时驱动程序调用系统服务就无需再通过 IPC （ inter-process communication ）陷入到内核中，而只需完成一个普通的函数调用过程，这样 IPC 和线程切换耗去的时间都会节省下来，自然效率会大大提高。但是在效率得到提升的同时，系统的稳定性却降低了，由于驱动程序运行在系统内核中，驱动程序的崩溃会对内核造成很严重的影响，甚至会导致内核的崩溃。为了得到较高的稳定性，可以让驱动程序运行于内核外，也就是让驱动程序以后两种方式来运行。
驱动程序的后两种运行方式的区别在于是否运行于客户端程序进程内，如果驱动程序只被某个应用使用，则完全可以让其运行在用户进程内，这样用户程序和驱动程序的交互无需通过 IPC ，但是驱动程序的崩溃会影响应用程序。如果驱动程序运行于内核外的进程外服务模块中，虽然效率会受损失，但由于客户端程序和驱动程序运行在不同的地址空间，当然作为客户端的用户程序会更稳定。
应当说明的是，驱动程序在上面三种方式下运行，并不需要改变驱动程序的源代码。而客户端程序如果不是特别声明要求驱动程序的运行方式，在驱动程序运行方式发生改变时，客户端程序也不需要修改，这时驱动程序的运行方式是由作为第三方的配置来决定的。
和欣操作系统的灵活内核技术和 ezCOM 技术使得构造具有上述的构件化驱动程序成为可能，其实这种模式同样适用于不涉及硬件的服务构件。和欣系统的内核和符合这种模式的服务构件组建起来的系统可以根据具体需要在多种性能之间进行选择，从而部分有效地解决整体内核和微内核之间的矛盾。
【参考文献】• 北京科泰公司资料 . 和欣操作系统简介 . 2002.8.
• A. Tanenbaum. Modern Operating Systems. Prentice-Hall 1993, 2nd edition 2001.
• Chris Dibora, Sam Ockman, and Mark Stone. Open Sources-voices from the Open Source Revolution. O'REILLY, 1999.
• Dale Rogerson, 杨秀章译 . COM 技术内幕微软组件对象模型 . 北京 : 北京清华大学出版社 , 1998.
• Giemn. M, Grob L. Microkernel based operating systems moving UNIX onto modern system architectures. In proc. Uniforum '92 conf. , USENIX Assoc, 1992.
Device driver design based on agile kernel Du Yongwen, He Huacan (Department of Computer Science and Engineering, Northwestern Polytechnical University)
(710072 Xi'an of China)
Chen Rong
(KoreTide Century. Inc. ， Beijing. 100029 ， Beijing of China)
Abstract: In this paper, for solving debates between micro-kernel and macro-kernel we propose component-based device driver on agile kernel of HEXIN operating system. The device driver which is built in this model can be executed under many domains. When device driver run in different domains, the system would gain different qualities.
keywords: component-based driver , component technique, operating system architecture
文章来源于领测软件测试网 https://www.ltesting.net/
