Disp BBS guest 註冊 登入(i) 線上人數: 877
首頁(home) 上頁(↑) 下頁(↓) 末頁(end)
看板 ott
作者 ott (寶貝)
標題 layered driver Architecture
時間 2013年10月25日 Fri. PM 11:35:48

       
     
   
 


layered driver Architecture



Windows® operating systems support a layered driver architecture. Every device is serviced by a chain of drivers, typically called a driver stack. Each driver in the stack isolates some hardware-dependent features from the drivers above it.


The following figure shows the types of drivers that could potentially be in a driver stack for a hypothetical device. In reality, few (if any) driver stacks contain all these types of drivers.  



[圖]
 



layered driver Architecture



As the preceding figure shows:
  1. Above the driver stack is an application. The application handles requests from users and other applications, and calls either the Win32® API or a routine that is exposed by the user-mode client driver. 

    2.
  2. A user-mode client driver handles requests from applications or from the Win32 API. For requests that require kernel-mode services, the user-mode client driver calls the Win32 API, which calls the appropriate kernel-mode client or support routine to carry out the request. User-mode client drivers are usually implemented as dynamic-link libraries (DLL). Printers support many operations that can be performed in user mode, and so typically have user-mode clients; disks and other storage devices, networks, and input devices do not.

    3.
  3. A kernel-mode client driver handles requests similar to those handled by the user-mode client, except that these requests are carried out in kernel mode, rather than in user mode.


    4.
  4. A device class and miniclass driver pair provides the bulk of the device-specific support. The class driver supplies system-required but hardware-independent support for a particular class of device. class drivers are typically supplied by Microsoft.

    5. A miniclass driver handles operations for a specific type of device of a particular class. For example, the battery class driver supports common operations for any battery, while a miniclass driver for a vendor's UPS device handles details unique to that particular device. Miniclass drivers are typically supplied by hardware vendors.  
  5. A corresponding port driver (for some devices, this is a host controller or host adapter driver) supports required I/O operations on an underlying port, hub, or other physical device through which the device attaches. Whether any such drivers are present depends on the type of device and the bus to which it eventually connects.

    6. All driver stacks for storage devices have aport driver. For example, the SCSIport driver provides support for I/O over the SCSI bus.

    For USB devices, a hub and host controller driver pair perform the duties of theport driver. These drivers handle I/O between the devices on the USB bus and the bus itself.

    A corresponding miniport driver handles device-specific operations for theport driver. For most types of devices, theport driver is supplied with the operating system, and the miniport driver is supplied by the device vendor.
  6. At the bottom of the figure is the hardware bus driver. Microsoft supplies bus drivers for all the major buses as part of the operating system. You should not attempt to replace these drivers.


Network drivers have their own unique terminology, defined in Windows 2000 and Later Network Architecture and the OSI Model. Nevertheless, network drivers are similarly layered, and each layer isolates device-specific or protocol-specific functionality from the layer above it.


Exactly which drivers are present, and what they are called, depends on the type of device and the bus to which it connects.



Graphics cards, for example, require a display driver, a videoport driver, and a video miniport driver. The display driver is analogous to the kernel-mode client driver in the previous figure. It provides general drawing capabilities and can often work with more than one graphics card. The videoport driver supports device-independent graphics operations. It works in tandem with the video miniport driver, which provides functionality that is specific to one graphics card (or a family of graphics cards). The paired video port/miniport drivers are analogous to the port/miniport drivers in the figure, and no class/miniclass drivers are present. For more information, see Display Architecture.


For simplicity, filter drivers are not shown in the previous figure. However, a filter driver can fit in at any layer of the driver stack above the hardware bus driver. A filter driver adds value to an existing driver by "filtering" — intercepting and manipulating device I/O. As a general rule, filter drivers do not operate the hardware directly, but work only on data and I/O requests passed to them from the next-higher or next-lower driver.


DirectShow®, the Microsoft software for video capture, includes system-supplied filter drivers that run in user mode. These filters act as clients of the kernel-mode stream class driver to expose the underlying video capture technology.

Built on Friday, April 11, 2003












http://msdn.microsoft.com/en-us/library/jj659821.aspx

Layered and monolithic drivers (Compact 2013)


8/28/2013

A device driver can be implemented as a  layered driver or a monolithic driver . layered drivers, also known as MDD/PDD drivers, split interface and hardware-specific functionality into two separate components: a model device driver (MDD) layer that contains the interface to the operating system and applications, and a platform device driver (PDD) layer that communicates with the underlying hardware.

Typically, each layer is packaged in a separate DLL. monolithic drivers, on the other hand, contain all device driver functionality in a single DLL. The following figure illustrates how these components interface the operating system to device hardware.



[圖]
 



Layered and Monolithic Device Drivers

The OS accesses each device driver type through a common device driver interface (DDI) so that layered drivers and monolithic drivers can be used interchangeably, without the OS having to know what type of architecture the device driver uses. The layered architecture defines an additional interface between the PDD and MDD layers, while the monolithic device driver architecture defines no explicit interface between its upper interface and the lower hardware-specific code.

Each device driver architecture type offers distinct advantages. monolithic drivers offer performance and resource-savings advantages while layered drivers offer advantages with regard to development costs, code reuse, and ease of updating. The layered device driver model simplifies the development and the process of porting device drivers. In the layered model, the developer only has to implement the PDD layer, reusing a common MDD layer that is already implemented for that class of hardware. For each device type that supports this layered architecture, Windows Embedded Compact includes an MDD implementation together with an implemented device driver for that device class. Many of the provided sample drivers use this layered organization because it reduces the amount of code that developers must write when porting the sample drivers to new devices.









MDDs have the following characteristics:

Contain code that is common to all drivers of a given type.

Call PDD functions to access the hardware.

Link to the PDD layer and define the device driver service provider interface (DDSI) functions that the MDD expects to call in that layer.

Expose device driver interface (DDI) functions to the operating system (OS).

Other parts of the OS can call these functions. Related devices can share the same DDI. Monolithic drivers also expose the DDI functions.

Handle interrupt processing.

Provide for reuse by developers.

Can link to multiple PDDs.

Generally require no changes.

If changed, you might have trouble migrating drivers to future versions.

Contain any interrupt service threads (ISTs).




PDDs have the following characteristics:

Consist of hardware platform specific code.

Might require modification for your hardware platform.

Are designed to work with specific MDD implementations.

Expose the DDSI functions that the MDD calls.

Monolithic drivers do not expose the DDSI functions.




The following list shows considerations for choosing between implementing a layered driver or a monolithic driver:

A layered driver might only require modification to the PDD.

A layered driver adds overhead to function calls in a device driver because the MDD calls into the PDD.

A monolithic driver improves driver performance because it combines the MDD and PDD into one layer, which removes the MDD's function calls into the PDD.

A monolithic driver is more difficult to migrate to future versions of Windows CE because most device drivers that Windows CE includes are divided into a PDD and an MDD.

A monolithic driver can be simpler and more efficient, if the capabilities of your device are well matched to the tasks that the functions in the MDD layer perform.

Regardless of whether you implement a layered driver or a monolithic driver, you can base your implementation on the source code for any of the sample drivers.











 
 






[圖]
 










※ 編輯: ott 時間: 2013-11-08 08:08:42
※ 看板: ott　文章推薦值: 0 目前人氣: 0 累積人氣: 192　
分享網址: 複製 已複製
→
guest
x)推文 r)回覆 e)編輯 d)刪除 M)收藏 ^x)轉錄 同主題: =)首篇 [)上篇 ])下篇