unix Mechanism vs Policy(机制与策略)

http://blog.csdn.net/ostrichmyself/article/details/5333558

http://blog.csdn.net/liuhaobupt/article/details/5350950

http://linux.chinaunix.net/techdoc/beginner/2006/06/06/933913.shtml

 

Unix文化贯穿始终的一条设计主线， 被翻译为： 机制， 而不是策略(Mechanism, not policy), 这句话的英文解释如下：

 

The distinction between mechanism and policy is one of the best ideas behind the Unix design. Most programming problems can indeed be split into two parts: “what capabilities are to be provided” (the mechanism) and “how those capabilities can be used” (the policy). If the two issues are addressed by different parts of the program, or even by different programs altogether, the software package is much easier to develop and to adapt to particular needs.

 

翻译过来：机制和策略的区别， Unix设计中最棒的思想之一， 大多程序的问题， 可以分离为两个问题： 提供什么样的功能(即机制)； 这些功能是怎么使用的(策略)。 如果在一个程序中的各个模块，甚至是不同程序间，突出强调这两个问题， 那么， 程序包将更容易开发并被特定的应用所采纳。

 

由此看来， Unix的设计偏重于程序提供什么样的功能， 并不注重程序是如何被用到的。 所谓提供什么样的功能，不仅仅指为User提供这样功能，还包括对其它模块或者其它程序提供这样的功能。 因此Unix注重功能设计，注重接口，但并不在乎这个功能会如何用到。所以，你用命令行，还是用GUI去调用， Unix设计者是不关心这个的。 他们在乎的是： OK， 我已经实现了这个功能了。

 

为什么用户觉得Unix不好用呢！ Unix程序员给你的答案是： 我不关心这个， 功能我已经实现了，并且，我跟其它模块和程序的接口完全解耦，API接口都是文本或者数据流，或者是协议。 我觉得事情已经OK了。

对于还是小白的用户来说，这样几乎是灭顶之灾，他很快就迷失，然后崩溃，最后出离愤怒， 这是显然的。

但对于程序员而言， 设想一下， 通过软件查询了一个结果，把它显示成在GUI上，渐变，渲染，若隐若现，跟我直观的打到shell上，区别在哪里?

程序员更应该关注机制，关注和外界的接口。 这就是为什么《Unix 编程艺术》 受到那么多程序员的追捧，无论是Linux用户还是windows，无论是C-Programer还是Java-Coder。 因为它关注的重点是架构。

 

《Unix编程艺术》中也给作者的理解： 因为策略和机制是按照不同的时间尺度变化的， 策略的变化要源源快于机制。 GUI工具包的观感时尚来去匆匆， 而光栅操作和组合确是永恒的。 这点跟设计模式的基本原则“分离可变和不变部分” 有着异曲同工， 只不过将其更加细化成“变化快和变化慢”的部分。

 

--------------------------------------------------------------------------------------------------------------

去年(2005)9月2号就买了Linux Device
Drivers第三版,但一直没仔细拜读.最近决定仔细研读它以学习Linux设备驱动程序. 在这里归纳学习笔记.
不知道自己有没有恒心把它看完,总之better later than never. 就让这一系列的笔记伴随我学习ldd3的漫漫长路吧

ldd3介绍的是2.6.10版的内核
An Introduction to Devices Drivers
驱动扮演的角色
Driver is a software layer that lies between the applications and the actual device.
Mechanism & Policy
" the role of a device driver is providing mechanism, not policy".
mechanism和policy也是隐藏在unix设计背后的经典思想. 
mechanism: What capabilities are provided.
policy          : How these capabilities can be used.
e.g1:   KDE or GNOME: 它们都的基础都是X server. KDE和GNOME属于policy.
它们所关注的是使用什么样的图形界面, 用户面板. 却无须考虑底层硬件. X server属于mechanism, 它与硬件交互,
并为用户程序提供接口. 所以不同的图形界面可以存在于同一台主机上.
e.g2: TCP/IP suite
OS提供socket接口, 应用程序则可以使用各种协议. socket就是mechanism, 应用程序则关注policy. 经典的OSI七层模型或TCP/IP四层模型也是这个思想.
Device Drivers: policy free, only provide mechanism!
but, sometimes, u may lay some policies on them.
和驱动一起发布的可能还会有一些库, 应用程序. 库和应用程序就要涉及到policies了.  开发者提供的库或应用程序中的policy即默认的policy.
Kernel可划分为下列功能单元
1, 进程管理: 进程调度, 资源分配, 进程间通信.
2, 内存管理: 其实也算是资源分配的一部分.
3, 文件系统: 管理, 组织物理媒介上数据的方法.
4, 设备控制: 设备驱动(ldd3所关注的)
5, 网络: 实质上是进程间通信. 但它不局限于一个特定的进程. 它关注收/发packets, 路由, 地址解析...
可加载模块(lodable modules)
module: 可实时加载到内核中的代码, 它可动态连接到内核(insmod, rmmod).
设备驱动就是module的代表, 但module还包括文件系统等等.
当然, 你也可以在开机后关闭模块的功能. 2.2版之后的内核支持在开机后关闭对加载module的支持.
设备, 模块的分类
针对不同的设备类型(实际上也就是文件类型, 可参考APUEv2, p88), 模块分为这些类型: character module, block module, network interface. 每种类型的模块驱动对应类型的设备.
字符设备: 以字节流的形式被访问的设备.
e.g: /dev/console : 文本控制台. /dev/ttyS0 : 串口
它通过文件系统节点被访问. e.g: /dev/tty1, /dev/lp0
字符设备与一般文件(regular file)的区别: 可以在一般文件中前后移动(lseek), 但只能顺序访问字符设备. 当然, 也有特例: frame grabbers.
块设备: 能支持文件系统的设备.
传统的UNIX: 只能以block(512B)为单位访问块设备.
Linux: 能以访问字符设备的方式访问块设备, 即以字节文单位访问块设备.
Linux中字符设备与块设备的区别:
1, 内核内部对数据的组织和管理不同, 但这对驱动开发者来说是透明的.
2, 它们与内核之间的接口不同: 使用两套不同的interface.
网络接口: 能与其他主机通信的设备.
它可以是硬件设备, 也可以是软件设备, 比如lo. (参考TCP/IP详解p26)
网络接口只管收发数据包, 而不管这些数据包被什么协议所使用.
不同于字符设备和块设备, 网络接口没有对应的文件系统节点. 虽然可以通过类似eth0这样的"文件名"来访问网络接口, 但文件系统节点中却没有针对网络接口的节点.
内核与网络接口之间的通信也不同于内核与字符/块设备之间的通信(read, write), 它们之间使用特定的传输数据包的函数调用.
另, 也有一些module不能严格地划分到上面的类型. 比如 USB module: 它工作在内核的USB子系统之上, 而实际的USB设备可以是字符设备, 块设备, 也可以是网络接口.

 

--------------------------------------------------------------------------------------------------

Unix有一个非常重要的文化，就是提供机制而不是策略。

 

Unix程序员更愿意相信用户自己更加清楚自己需要的是什么，所以他们更倾向于为用户提供的是用户实现自身所需的手段，而不简单是用户直接的必需品。因此，可能每一个真正的Unix用户，都需要对系统本身、以及自己所需有一个认识，用广大Unix程序员提供的工具，去完成自身的任务。