2.7 设备驱动模型
根据设备驱动程序运行的状态，当前有两种类型的驱动模型。在第一种模型中，驱动以模块的方式在系统内核中，通常桌面操作系统和大型服务器操作系统采用这种模型，例如Linux、UNIX、Windows XP等[44]。另外一种模型是将设备驱动线程化，就是驱动程序作为可被调度的线程运行，通常由事件驱动，采用这一类设备驱动模型的一般是实时嵌入式操作系统或者是微内核操作系统，例如L4、QNX等。在第一种模型中，由于系统内核和设备驱动模块在同一个地址空间，因此驱动响应设备中并提供服务较快。第二种模型中，如果任务想访问底层物理设备，它们必须通过内核提供的IPC工具向驱动服务例程发送服务请求，如此以来，增加了任务获取底层驱动服务的额外开销[45]。因此，第二种任务被大家认作是很低效的。但是，一些研究工作者已经开始通过试验来纠正这种观点，并且已经取得了一些研究成果[46]。但是，在第二种驱动模型上，虽然在性能方面存在争议，但确存在一项得到广泛赞同的结构优势。采用线程的驱动模型是将设备驱动与系统内核分离，在降低系统内核复杂度的同时避免了设备驱动程序对系统内核的威胁，从而提高了系统内核的安全性和可靠性。
作为一个Hypervisor系统，XtratuM可以并行支持多种域或操作系统。当前，正如前面所说，XtratuM是基于Linux的，并且Linux是根域(Root Domain)。普通的设备驱动程序在根域中，也就意味着如果其余的域想访问或使用设备，例如串口，它们必须通过Linux系统，但是Linux设备驱动不支持实时驱动程序，从而给整个系统的安全性、可靠性、有效性带来问题。因此，新的设备驱动模型必须构建，以适应XtratuM中实时任务的需要。
在微内核(Micro-Kernel)系统中，设备驱动程序以独立的被调度服务程序在内核外部运行。设备驱动程序为其它客户任务提供服务。如果客户任务想获取设备驱动程序提供的服务，它们必须首先向内核放送服务请求，然后系统内核将服务请求信息传输给设备驱动服务程序，最后响应信息依然通过系统内核从驱动服务程序传输到客户程序。通常，一些高效的IPC工具，例如消息队列、FIFO、信号等被用来在内核、设备服务程序和客户程序之间传输信息和数据。
XtratuM Hypervisor也采用微内核系统中设备驱动模型的这一特点，设备驱动以独立的系统任务运行，但是与微内核系统环境相比，运行于XtratuM系统上的不是进程或线程任务，而是域，具有自己独立的内核和用户空间。因此，在XtratuM驱动模型中，作为运行于XtratuM内核外部的设备驱动程序，不再是简单的任务，而是一个具有最高优先级的独立域。设备驱动在私有内存空间独立运行，并且对相关设备中做出响应。在模型中，客户域和服务域(即设备驱动程序)是通过IDC（Inter-Domain Communication）工具进行通信，例如FIFO、共享内存等[47]。
2.7.1 模型架构
在XtratuM Hypervisor系统中，有两种方法可以被用来创建设备驱动程序，重新利用Linux设备驱动程序或者是提供在XtratuM 系统中提供核心驱动程序的APIs的实时安全变种。在XtratuM驱动模型(XtratuM Device Driver Model)中，采用了一种新的策略：复用Linux设备驱动程序提供的初始化代码，并且重新编写设备驱动程序的运行时部分。根据该策略，设备驱动被分为两部分，驱动的初始化模块以及设备驱动服务模块。图2-15给出了XtratuM系统中的设备驱动模型。
图2-15. XtratuM设备驱动模型
在模型中，环境配置和驱动初始化任务将会在Linux模块中完成，其中包含初始化中断寄存器、设备保护、内存分配等。但是重要的中断响应任务是由设备驱动程序服务域完成。在XtratuM驱动模型中，设备驱动域具有最高优先级，从而可以保证任务执行时不会被其它的域中断。并且当中断发生时，具有最高优先级的域将会被调度和执行。在设备驱动模型中，通常，设备驱动域会被加载进系统后，就会将自己挂载起来直到相应中断方法或其它事件触发。
图2-16. 复用Linux设备驱动XtratuM实时安驱动模型
设备驱动模型中，设备驱动服务域应该具有多种功能，例如应该可以运行时配置硬件，并且可以从设备寄存器中读写数据，以及执行一些设备支持的特殊操作，更重要的是设备驱动域应该可以为客户域提供服务。当然，设备驱动服务域的功能并不仅仅局限于此。
为了便于客户域和设备驱动服务域之间的通信，一些通信工具或IDC应该在驱动模型中创建或使用，例如FIFO、消息队里、共享内存、信号等。通常这些通信工具的使用并不是很固定，IDC的选择要根据具体的设备驱动，例如FIFO适应于串口设备驱动使用，而共享内存则适合于磁盘等块设备驱动程序。