Linux设备驱动模型

转自：http://blog.csdn.net/fivedoumi/article/details/50913615

设备驱动模型的作用：

1）设备驱动模型实现uevent机制，调用应用层的mdev来自动创建设备文件。

2）设备驱动模型通过sysfs文件系统向用户层提供设备驱动视图。

         设备是具体的一个个设备，在/sys/devices/是创建了实际的文件节点。而其他目录，如设备类和总线以下的子目录中出现的设备都是用符号链接指向/sys/devices/目录下的文件。

设备类是对/sys/devices/下的各种设备进行归类，以体现一类设备的公共属性，如鼠标和触摸屏都是属于input设备类。

         总线目录是总线、设备、驱动模型的核心目录。因为设备和驱动都是依附在某种总线上的，如USB、PCI和平台总线等。设备和驱动正是依靠总线的管理功能才能找到对方，如设备注册到总线时去寻找驱动，而驱动注册的时候去寻找其能够支持的设备。

         事实上，内核中的总线class、设备device和驱动device_driver都不会将所有的信息暴露给用户层，例如这三个数据结构都有对应的private数据结构，它用于内核对上下级总线设备驱动的链表关系维护。如果暴露给用户层，那容易被用户层修改而使系统混乱。实际上，用户层只关心三者的视图关联，至于他们的关联在底层怎么实现则不需要关心。

         3）设备驱动模型提供统一的电源管理机制。很明显，我们在字符设备驱动的file_operations接口中并没有看到电源管理方面的接口。而对于操作系统来说，电源功耗管理必不可少。电源管理其实不应该由应用开发人员来负责，而是应该由系统来负责，例如手机很久没有触摸了，那会进入休眠状态。这种状态的改变应该由系统来完成，而各种设备进入睡眠模式也应该由系统来完成。因此file_operations不提供电源管理的接口给应用程序是合理的。而设备模型作为系统管理的一种机制，由它来提供电源管理是非常合理的。

         如设备device数据结构有struct dev_pm_info power功耗属性参数，驱动device_driver数据结构有struct dev_pm_ops *pm功耗操作接口。

         4）设备驱动模型提供各种对象实例的引用计数，防止对象被应用层误删。设备模型的所有数据结构均是继承kobject而来，而kobject就提供基础的计数功能。

         5）设备驱动模型提供多一种方式给应用层，用户和内核可以通过sysfs进行交互，如通过修改/sys目录下设备的文件内容，即可以直接修改设备对应的参数。

         总结，设备驱动模型侧重于内核对总线、设备和驱动的管理，并向应用层暴露这些管理的信息，而字符设备驱动则侧重于设备驱动的功能实现。