中财网皇太极几岁登基:Mechanism vs Policy
来源：百度文库 编辑：中财网 时间：2024/05/09 07:17:03
机制与策略
已有 3298 次阅读 2009-10-17 09:50 |关键词:Linux 机制 lupa php 功能 开发 软件 开源 操作系统 用户 系统 硬件 内核
Unix/Linux的接口设计有一句通用的格言“提供机制而不是策略”。区别对待机制（mechanism）和策略（policy）是Unix设计中的一大亮点。大部分的编程问题都可以被切割成两个部分：“需要提供什么功能”（机制）和“怎样实现这些功能”（策略）。如果由程序中的独立部分分别负责机制和策略的实现，那么开发软件就更容易，也更容易适应不同的需求。开源-展现在我们面前的是数以千计的代码，在那一行行的代码背后，到底蕴藏着怎样的设计思想，高手们曾怎样苦思冥想。在一堆堆的代码面前，有时候，我们很容易迷失曾经进来的入口，而掉入符号，变量以及函数堆积成的沼泽地。
操作系统的本质是什么？管理者？亦或服务者？但，归根结底，它是一个执行者：执行用户程序-所谓为用户服务；执行中断-所谓为外设服务；执行系统调用-所谓解放程序员（姑且说它为广大的程序员服务，因为程序员不再与繁杂的硬件打交道了）；执行内核线程-为操作系统自身服务。而这所有执行的核心，无非是在恰当的时机，让哪个对象（程序，线程，中断服务程序，中断的下半部，系统调用）占有CPU。换句话说，Unix/Linux抽象出对这些对象的执行机制:
- 程序的执行机制-进程
- 内核函数的执行机制-线程
- 中断服务程序的执行机制-中断信号触发
- 中断下半部的执行机制-softirq，tasklet，工作队列
- 系统调用的执行-软中断（int $0x80触发）
如果说机制是一种框架，那么，策略就是填充框架的一个个具体实体。机制提供的是一种开放而宽松的环境，而策略就是在这个环境下赖以生存的生命个体。比如，我们编写的一个程序，fork()以后，就成为一个个进程的生命个体。而操作系统所提供给我们创建、执行以及结束进程的各种原语 -fork(),exex()和exit（）等是统管各种进程的机制。我们所创建进程的死活并不会影响机制本身。
如此看来，也许我们对原理之困惑有所醒悟。我们任何人在任何时候都可以调用fork()创建N多进程。这样一个简单的fork（）壳，想追根溯源者，剥开这个壳，可以看到其五脏六腑。fork()如果出现任何一个小bug，直接影响到我们任何人和任何进程。
如此看来，也许我们对开发者所承担的角色有所感悟。系统分析员和设计人员，任重而探究的路漫漫兮。说到此，设计模式等系列书，对有志于从编码走向设计的开发者或许有所启发。
http://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy
The separation of mechanism and policy[1] is a design principle in computer science. It states that mechanisms (those parts of a system implementation that control the authorization of operations and the allocation of resources) should not dictate (or overly restrict) the policies according to which decisions are made about which operations to authorize, and which resources to allocate.
This is most commonly discussed in the context of security mechanisms (authentication and authorization), but is actually applicable to a much wider range of resource allocation problems (e.g. CPU scheduling, memory allocation, Quality of Service), and the general question of good object abstraction.
Per Brinch Hansen presented arguments in favor of separation of mechanism and policy.[2][3]
Artsy, in a 1987 paper, discussed an approach for an operating system design having an "extreme separation of mechanism and policy".[4][5]
In a 2000 article, Chervenak et al. described the principles of mechanism neutrality and policy neutrality.[6]
Rationale and Implications
The separation of mechanism and policy is the fundamental approach of a microkernel that distinguishes it from a monolithic one. In a microkernel the majority of operating system services are provided by user-level server processes.[7] It is considered important[by whom?] for an operating system to have the flexibility of providing adequate mechanisms to support the broadest possible spectrum of real-world security policies.[8]
It is almost impossible to envision all of the different ways in which a system might be used by different types of users over the life of the product. This means that any hard-coded policies are likely to be inadequate or inappropriate for some (or perhaps even most) users. Decoupling the mechanism implementations from the policy specifications makes it possible for different applications to use the same mechanism implementations with different policies. This means that those mechanisms are likely to better meet the needs of a wider range of users, for a longer period of time.
If it is possible to enable new policies without changing the implementing mechanisms, the costs and risks of such policy changes can be greatly reduced. In the first instance, this could be accomplished merely by segregating mechanisms and their policies into distinct modules: by replacing the module which dictates a policy (e.g. CPU scheduling policy) without changing the module which executes this policy (e.g. the scheduling mechanism), we can change the behaviour of the system. Further, in cases where a wide or variable range of policies are anticipated depending on applications' needs, it makes sense to create some non-code means for specifying policies, i.e. policies are not hardcoded into executable code but can be specified as an independent description. For instance, file protection policies (e.g. Unix's user/group/other read/write/execute ) might be parametrized. Alternatively an implementing mechanism could be designed to include an interpreter for a new policy specification language. In both cases, the systems are usually accompanied by a deferred binding mechanism (e.g. configuration files, or APIs) that permits policy specifications to be incorporated to the system or replaced by another after it has been delivered to the customer.
An everyday example of mechanism/policy separation is the use of card-keys to gain access to locked doors. The mechanisms (magnetic card readers, remote controlled locks, connections to a security server) do not impose any limitations on entrance policy (which people should be allowed to enter which doors, at which times). These decisions are made by a centralized security server, which (in turn) probably makes its decisions by consulting a database of room access rules. Specific authorization decisions can be changed by updating a room access database. If the rule schema of that database proved too limiting, the entire security server could be replaced while leaving the fundamental mechanisms (readers, locks, and connections) unchanged.
http://blog.csdn.net/liuhaobupt/article/details/5350950
Unix有一个非常重要的文化，就是提供机制而不是策略
Unix程序员更愿意相信用户自己更加清楚自己需要的是什么，所以他们更倾向于为用户提供的是用户实现自身所需的手段，而不简单是用户直接的必需品。因此，可能每一个真正的Unix用户，都需要对系统本身、以及自己所需有一个认识，用广大Unix程序员提供的工具，去完成自身的任务。
感觉说的可能不是一个意思，一个说法可能是接口与实现的区别，另一说法可理解为手段与如何使用手段的区别。前一种理解则可以对应于“get right things done” 与 “do things right”的联系。