机制mechanism，策略policy。如果你看过《linux device drivers》，里面给出了大概的介绍。机制提供了干什么(do what),策略提供如何做（how to do）。驱动程序完成机制的功能，把策略的实现留给用户的应用程序。
通常在机制中，驱动程序要完成打开，关闭，读写，控制等功能。这些都是设备使用时最基本的操作。而策略中就要实现一些高级的数据处理或界面功能。通过例子来说明会更好些。 以RTC（实时时钟设备）为例。假设RTC共有8个REG，分别是2个控制寄存器、年寄存器、月寄存器、日寄存器、时寄存器、分寄存器、秒寄存器。RTC的启动和关闭分别通过设定控制寄存器的某一个位来完成。 1. 驱动程序提供open,release,write,read函数。Open和release不多说了，具体介绍一下read和write的功能。Read中通过IO端口操作可以读入这8个寄存器的值，Write中通过IO端口操作可以写入这8个寄存器的值。仅仅这样驱动程序已经为应用程序提供了所有完成对RTC设备访问的接口。这样或许对应用程序操作RTC不是很方便，因此在发布驱动程序的时候，我们提供了针对RTC的用户函数库。比如setDate,setTime等，这些函数无非就是把驱动程序中的read和write组合调用了一下。但是采用这种策略，用户写应用程序时就会更方便，对底层的细节就不必知道的太多。 2. 另一个可以选择的机制就是驱动程序中引入ioctl函数，驱动程序把setDate,setTime操作的功能在ioctl函数中实现。Ioctl通过IO端口操作访问8个寄存器就可以完成。将来驱动程序发布时，不用提供用户函数库。只要告诉开发人员IOCTL函数的操作码即可，使用不同的ioctl调用就可以完成setDate,setTime功能。 通过上面两种情况可以看出，机制不同提供的策略选择不同，机制可以把策略中的一些功能集成。但是如何选择正确的机制和策略组合呢？ 针对上面2中机制提供，分析各自优缺点： 第一种方案中，由于没有提供Ioctl函数，驱动程序必然会占用内存小。而且对于RTC设备，我们不会经常去setDate,setTime，因此这种小概率使用的函数放到用户库中实现更好。 第二中方案，不用提供用户函数库，发布方便。但是ioctl函数会常驻内存中，尽管他可能一直得不到调用！这中方式更符合面向对象的编程思想。 |
楼主
标题置顶
标题高亮
