2.6内核增加了一个引人注目的新特性——统一设备模型(device model)。设备模型提供了一个独立的机制专门来表示设备，并描述其在系统中的拓扑结构，从而使得系统具有以下优点：
l代码重复最小化。
l提供诸如引用计数这样的统一机制。
l可以列举系统中所有的设备，观察它们的状态，并且查看它们连接的总线。
l可以将系统中的全部设备结构以树的形式完整、有效的展 现出来——包括所有的总线和内部连接。
l可以将设备和其对应的驱动联系起来，反之亦然。
l可以将设备按照类型加以归类，比如分类为输入设备，而无需理解物理设备的拓扑结构。
l可以沿设备树的叶子向其根的方向依次遍历，以保证能以正确顺序关闭各设备的电源。

{zh1}一点是实现设备模型的最初动机。若想在内核中实现智能的电源管理，就需要来建立表示系统中设备拓扑关系的树结构。当在树上端的设备关闭电源时，内核必须首先关闭该设备节点以下的（处于叶子上的）设备电源。比如内核需要先关闭一个USB鼠标，然后才可关闭USB控制器；同样内核也必须在关闭PCI总线前先关闭USB控制器。简而言之，若要准确而又高效的完成上述电源管理目标，内核无疑需要一颗设备树。(注：设备模型与电源管理相关联，貌似匪夷所思，可实际上，一个新观点或模型出现，在其背后都是需求的刺激。最近以来，节电一直是Intel、IBM等大公司孜孜追求的目标，虚拟化技术的本质其实就是节能。或者说，在能源日趋紧张的今日，节能是人类共同追求的目标)。

为什么驱动模型有助于电源管理，再说两句：
系统中所有硬件设备由内核全权负责电源管理。例如，在以电池供电的计算机进入“待机”状态时，内核应立刻强制每个硬件设备（硬盘，显卡，声卡，网卡，总线控制器等等）处于低功率状态。因此，每个能够响应“待机”状态的设备驱动程序必须包含一个回调函数，它能够使得硬件设备处于低功率状态。而且，硬件设备必须按准确的顺序进入“待机”状态，否则一些设备可能会处于错误的电源状态。例如，内核必须首先将硬盘置于“待机”状态，然后才是它们的磁盘控制器，因为若按照相反的顺序执行，磁盘控制器就不能向硬盘发送命令。

转自：

=================================

这个模型很吸引人，如果可能，真的希望将其引入到COOCOX OS中，不过要这一复杂的模型，对于CoOS来说太过于复杂。

如果实现可以从以下方向考虑，不过在设计之前要了解清楚这一模型的好坏：

若想在内核中实现智能的电源管理，就需要来建立表示系统中设备拓扑关系的树结构。当在树上端的设备关闭电源时，内核必须首先关闭该设备节点以下的（处于叶子上的）设备电源。比如内核需要先关闭一个USB鼠标，然后才可关闭USB控制器；同样内核也必须在关闭PCI总线前先关闭USB控制器。简而言之，若要准确而又高效的完成上述电源管理目标，内核无疑需要一颗设备树。

每个能够响应“待机”状态的设备驱动程序必须包含一个回调函数，它能够使得硬件设备处于低功率状态。