Design Goals And Tradeoffs - Learning Module

Loading content...

0/227

Policy vs Mechanism

The Separation That Shapes Everything

Consider a simple question: How should the operating system decide which process runs next?

This seemingly straightforward question actually contains two very different questions:

What are the rules? — Should we prioritize interactive applications? Ensure fairness? Minimize latency? Maximize throughput? The answer depends on the system's purpose: a desktop needs responsiveness, a batch server needs throughput, a real-time controller needs predictable timing.
How do we implement those rules? — How do we track process states, measure CPU time, switch between processes, and handle priorities? These mechanisms are largely independent of which rules we choose.

The distinction between these questions—policy (what to do) versus mechanism (how to do it)—is one of the most important principles in operating system design. It appears everywhere:

CPU scheduling: The scheduler mechanism can execute any scheduling policy
Memory management: Page replacement mechanisms implement various replacement policies
I/O systems: Request ordering mechanisms serve different policies (fairness, throughput, latency)
Security: Access control mechanisms enforce various authorization policies

This separation is so fundamental that understanding it will change how you think about system design.

What You Will Learn

By the end of this page, you will understand the policy-mechanism separation deeply. You'll see how this principle enables flexibility without complexity, why it's essential for system evolution, and how to apply it in your own designs. You'll recognize policy-mechanism patterns in systems you use and build.

Understanding Policy and Mechanism

Let's establish precise definitions for these foundational concepts:

Mechanism answers: "How is something accomplished?"

Mechanisms are the tools, primitives, and infrastructure that enable actions. They are general-purpose building blocks that don't embed specific decisions about their use. Mechanisms should be:

Neutral about how they're used
Complete enough to support various policies
Efficient in implementation
Stable over time

Policy answers: "What should be done?"

Policies are the decisions, rules, and algorithms that determine behavior. They use mechanisms to achieve goals but don't implement the underlying capabilities. Policies should be:

Separate from the mechanisms they use
Configurable or replaceable
Appropriate for the deployment context
Evolvable as requirements change

Policy vs Mechanism Examples
Domain	Mechanism	Policy
CPU Scheduling	Context switch, timer interrupts, run queues	Round-robin, priority-based, CFS, real-time
Memory Management	Page tables, TLB, swap I/O	LRU replacement, working set, demand paging
File Systems	Directory structures, inode tables, caching	Naming conventions, quota limits, access control
Process Management	Process creation, IPC primitives, signals	Parent-child relationships, resource limits
I/O Systems	Device drivers, request queues, DMA	Deadline scheduling, throughput optimization
Security	Capability bits, ACLs, encryption primitives	DAC, MAC, RBAC, attribute-based control

The Key Insight:

Mechanisms are relatively stable; policies change frequently. Hardware evolves slowly; user requirements change constantly. By separating what changes from what doesn't, we can:

Update policies without rebuilding mechanisms
Share mechanisms across different policies
Test mechanisms and policies independently
Allow administrators to customize behavior without coding
Enable research on new policies using production mechanisms

The Layering Principle

Think of mechanisms as a language and policies as what you say in that language. The language provides expressive power; the message determines meaning. A well-designed mechanism is like a well-designed language: it can express many different ideas without constraining what can be said.

Historical Origins and Evolution

The policy-mechanism separation principle emerged from hard-won experience in early operating system development.

The Multics Contribution:

Multics (Multiplexed Information and Computing Service), developed at MIT in the 1960s, was one of the first systems to explicitly recognize this separation. Its designers observed that:

Different installations had different requirements
What worked for one site might not work for another
Requirements changed faster than system software could be rewritten

Multics introduced configurable policies for security, resource allocation, and system administration—while core mechanisms remained stable.

The Unix Simplification:

Unix, created partly as a reaction to Multics' complexity, nevertheless embraced the policy-mechanism separation. Unix provided minimal mechanisms with maximum flexibility:

Process creation (fork/exec) as mechanism; shell scripts as policy
File permissions as mechanism; group membership as policy
Signals as mechanism; application-defined handlers as policy

unix_policy_mechanism.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# Unix Policy-Mechanism Separation in Action
 
# MECHANISM: The kernel provides process reaping
# POLICY: What happens when parent doesn't wait?
 
# Option 1 (Traditional): Orphans adopted by init (PID 1)
# - init calls wait() for all orphans
# - Policy: System cleans up orphans automatically
 
# Option 2 (Modern): Process groups and sessions
# - systemd manages service hierarchies
# - Policy: Service manager tracks and cleans up processes
 
# MECHANISM: The kernel provides signals
# POLICY: How applications respond
 
# Application defines signal policy:
trap 'echo "Caught SIGTERM, cleaning up..."; cleanup; exit 0' SIGTERM
trap 'echo "Ignoring SIGHUP"' SIGHUP
trap '' SIGINT  # Ignore interrupt
 
# Same mechanism (signals), different policies per application
 
# MECHANISM: Nice values and scheduling classes
# POLICY: Which processes get priority
 
nice -n 19 ./background_job.sh    # Low priority (policy decision)
chrt -f 99 ./realtime_task        # Real-time priority (policy decision)
 
# The kernel doesn't know or care about the intended use;
# it just implements the priority mechanism

The Microkernel Philosophy:

Microkernels take policy-mechanism separation to its logical extreme. The kernel provides only the most fundamental mechanisms:

Address space isolation
Thread scheduling primitives
Inter-process communication

Everything else—file systems, device drivers, networking—runs as user-space servers that implement policies using kernel mechanisms. This allows policy changes without kernel modification:

Want a different file system? Replace the file server.
Need custom scheduling? Implement your own scheduler server.
Require specialized security? Deploy a custom security manager.

While pure microkernels have performance challenges, their extreme separation demonstrates the principle clearly.

Modern Manifestation

Today's container orchestrators like Kubernetes exemplify policy-mechanism separation. Kubernetes provides mechanisms (pods, services, deployments). Operators define policies (how many replicas, when to scale, what resources to allocate). The mechanism doesn't change; thousands of different policies run on the same platform.

Case Study: CPU Scheduling

CPU scheduling provides a textbook example of policy-mechanism separation. Let's examine this in detail.

The Scheduling Mechanism:

The kernel must provide certain capabilities regardless of scheduling policy:

Scheduling Mechanisms

•Context switching — Save one process's state, restore another's. Architecture-specific but policy-neutral.
•Timer interrupts — Periodic interrupts that give the scheduler opportunities to run.
•Run queues — Data structures to track ready-to-run processes. Various implementations possible.
•Priority levels — Numeric values that influence scheduling. Meaning is policy-defined.
•CPU affinity — Ability to restrict processes to specific CPUs. How used is policy.
•Preemption — Ability to interrupt running processes. When to preempt is policy.

Scheduling Policies:

Given these mechanisms, many different policies can be implemented:

scheduling_policies.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
/**
 * Scheduling Policies Using Common Mechanisms
 * 
 * All policies use the same mechanisms:
 * - Run queues for tracking processes
 * - Context switch for changing active process  
 * - Timer for time accounting
 */
 
// ========== Policy: Round Robin ==========
struct task *round_robin_select(struct run_queue *rq) {
    // Move front of queue to back, return new front
    struct task *current = dequeue_front(rq);
    enqueue_back(rq, current);
    return rq->front;
}
 
void round_robin_timer_tick(struct run_queue *rq) {
    rq->current->time_slice--;
    if (rq->current->time_slice <= 0) {
        rq->current->time_slice = QUANTUM;
        schedule();  // Force reschedule
    }
}
 
 
// ========== Policy: Priority-Based ==========
struct task *priority_select(struct run_queue *rq) {
    // Always run highest priority ready task
    return rq->priority_queues[rq->highest_nonempty];
}
 
void priority_task_wakeup(struct task *task) {
    // Insert at head of its priority queue
    insert_at_priority(task->run_queue, task, task->priority);
}
 
 
// ========== Policy: Linux CFS (Completely Fair Scheduler) ==========
struct task *cfs_select(struct cfs_rq *rq) {
    // Red-black tree ordered by virtual runtime
    // Leftmost node has smallest vruntime (most deserving)
    return rb_entry(rq->rb_leftmost, struct task, run_node);
}
 
void cfs_update_vruntime(struct task *task, uint64_t delta) {
    // Higher weight = slower vruntime accumulation = more CPU time
    task->vruntime += delta * NICE_0_WEIGHT / task->weight;
    // Rebalance in tree if order changed
    rebalance_rb_tree(task);
}
 
 
// ========== Policy: Real-Time (FIFO and RR) ==========
struct task *rt_select(struct rt_rq *rq) {
    // Real-time tasks always preempt normal tasks
    // Among RT tasks: highest priority, FIFO within priority
    for (int prio = 0; prio < MAX_RT_PRIO; prio++) {
        if (!list_empty(&rq->active.queue[prio])) {
            return list_first_entry(&rq->active.queue[prio], 
                                    struct task, run_list);
        }
    }
    return NULL;  // No RT tasks, fall back to CFS
}
 
/**
 * KEY INSIGHT:
 * 
 * All four policies use the same mechanisms:
 * - Process state tracking
 * - Run queue data structures  
 * - Timer interrupts
 * - Context switching
 * 
 * The mechanism doesn't know or care which policy is active.
 * Policies can be changed at runtime without mechanism changes.
 */

Linux Scheduling Classes:

Linux implements multiple scheduling policies simultaneously using scheduling classes:

linux_sched_classes.txt

Text

Linux Scheduling Architecture
 
┌─────────────────────────────────────────────────────────────┐
│                    Core Scheduler                            │
│  (Mechanism: context switch, timer handling, load balancing) │
└─────────────────────────────────────────────────────────────┘
                              │
                              │ calls into scheduling classes
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                   Scheduling Classes                         │
│                                                              │
│  ┌────────────┐  ┌────────────┐  ┌────────────┐            │
│  │  stop_sched │  │  dl_sched  │  │  rt_sched  │            │
│  │  (highest)  │  │ (deadline) │  │ (real-time)│            │
│  └────────────┘  └────────────┘  └────────────┘            │
│                                                              │
│  ┌────────────┐  ┌────────────┐                             │
│  │ fair_sched │  │ idle_sched │                             │
│  │   (CFS)    │  │  (lowest)  │                             │
│  └────────────┘  └────────────┘                             │
│                                                              │
│  Each class implements:                                      │
│  - enqueue_task() / dequeue_task()                          │
│  - pick_next_task()                                         │
│  - put_prev_task()                                          │
│  - check_preempt_curr()                                     │
│  - task_tick()                                              │
│                                                              │
└─────────────────────────────────────────────────────────────┘
 
User controls:
$ chrt -f 50 ./program    # SCHED_FIFO (rt_sched) priority 50
$ chrt -d --sched-deadline 10000000 ./program  # Deadline scheduling
$ nice -n 5 ./program     # CFS with niceness 5
$ chrt -i 0 ./program     # SCHED_IDLE (run only when nothing else)
 
Same mechanisms, radically different policies for different needs.

Extensibility Through Separation

Because Linux separates scheduling mechanisms from policies, adding a new scheduling class (like SCHED_DEADLINE in 2014) required no changes to the core scheduler. The new policy simply implements the scheduling class interface and plugs in. This is the power of policy-mechanism separation: evolution without revolution.

Case Study: Memory Management

Memory management provides another clear illustration of policy-mechanism separation, particularly in page replacement.

Memory Management Mechanisms:

•Page tables — Hardware structures mapping virtual to physical addresses
•TLB management — Caching of recent translations; invalidation on process switch
•Page fault handling — Trap when accessing unmapped page; framework for policy decision
•Swap I/O — Reading/writing pages to backing store
•Page tracking — Recording access and modification bits for policy use
•Memory zones — Organizing physical memory by characteristics (DMA-able, high memory)

Page Replacement Policies:

When physical memory is exhausted, something must be evicted. The mechanism provides the capability; policy decides what to evict:

Page Replacement Policies
Policy	Algorithm	Pros	Cons
FIFO	Evict oldest page	Simple, low overhead	Ignores usage patterns; Belady's anomaly
LRU	Evict least recently used	Good locality tracking	Expensive to track exactly
LRU Approximation (Clock)	Approximate LRU using reference bits	Efficient, nearly as good as LRU	Not exact LRU
Working Set	Keep recently used pages	Adapts to process behavior	Must choose window size
2Q / LIRS	Track hot vs cold pages	Better than LRU for scans	More complex implementation

page_replacement.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
/**
 * Page Replacement: Same Mechanism, Different Policies
 */
 
// ========== Mechanism: Page Fault Handler ==========
void handle_page_fault(unsigned long address) {
    struct page *page;
    
    if (!is_valid_address(address)) {
        send_signal(current, SIGSEGV);
        return;
    }
    
    if (memory_available()) {
        // Simple case: allocate new page
        page = alloc_page();
    } else {
        // Memory pressure: invoke page replacement POLICY
        page = page_replacement_policy->find_victim();
        if (page->dirty) {
            write_page_to_swap(page);
        }
    }
    
    // Map the page and resume (mechanism)
    map_page(current->mm, address, page);
}
 
// ========== Policy Interface ==========
struct page_replacement_policy {
    struct page *(*find_victim)(void);
    void (*page_accessed)(struct page *page);
    void (*page_added)(struct page *page);
    void (*page_removed)(struct page *page);
};
 
// ========== Policy: FIFO ==========
struct page *fifo_find_victim(void) {
    // Simply return the oldest page
    return list_first_entry(&page_list, struct page, lru);
}
 
void fifo_page_added(struct page *page) {
    // Add to tail of list
    list_add_tail(&page->lru, &page_list);
}
 
// ========== Policy: LRU Approximation (Clock) ==========
struct page *clock_find_victim(void) {
    while (1) {
        struct page *page = clock_hand;
        clock_hand = list_next_entry(clock_hand, lru);
        
        if (page->referenced) {
            // Give second chance
            page->referenced = 0;
        } else {
            // Found victim
            return page;
        }
    }
}
 
void clock_page_accessed(struct page *page) {
    // Hardware sets reference bit; we read it
    page->referenced = 1;
}
 
// ========== Policy: Working Set Based ==========
struct page *working_set_find_victim(void) {
    unsigned long cutoff = jiffies - working_set_window;
    
    list_for_each_entry(page, &page_list, lru) {
        if (page->last_access < cutoff) {
            // Not in working set
            return page;
        }
    }
    // All pages in working set - expand or use secondary policy
    return fallback_policy->find_victim();
}
 
/**
 * The page fault handler (mechanism) is identical regardless of
 * which policy is active. Policies can be swapped at runtime.
 * Different memory-pressure scenarios might use different policies.
 */

Linux's Approach: Multiple Policies Simultaneously

Linux doesn't use a single page replacement policy. It uses multiple mechanisms together: active/inactive lists (like 2Q), page aging based on reference bits, memory cgroupcgroups for isolation, and different reclaim strategies based on pressure level. The mechanisms enable this rich policy landscape.

Design Principles for Policy-Mechanism Separation

Applying policy-mechanism separation effectively requires careful design. Here are principles that guide good separation:

Principle 1: Mechanisms Should Be Policy-Neutral

Mechanisms should not embed assumptions about how they'll be used:

Good: Policy-Neutral

•Priority values are just numbers (meaning is policy)
•Timer provides time; doesn't decide timeout values
•IPC delivers messages; doesn't enforce protocols
•Permissions are bits; interpretation is policy

Bad: Policy-Embedded

•Priority 10 always means 'critical system process'
•Timeout is always 30 seconds (hardcoded)
•IPC only works for specific message formats
•Specific users get hardcoded special treatment

Principle 2: Mechanisms Should Be Complete

Mechanisms must provide enough capability to support the full range of reasonable policies. An incomplete mechanism forces policies to work around limitations:

mechanism_completeness.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
/**
 * Mechanism Completeness Example: Resource Limits
 */
 
// ========== Incomplete Mechanism ==========
// Only allows setting a single hard limit
struct rlimit_v1 {
    uint64_t max;  // Absolute maximum
};
// Problem: Can't express "warn at 80%, enforce at 100%"
// Problem: Can't express "soft limit that can be raised"
// Policies requiring these concepts can't be implemented.
 
 
// ========== Complete Mechanism ==========
struct rlimit_v2 {
    uint64_t soft_limit;   // Warning/default limit
    uint64_t hard_limit;   // Absolute maximum
    uint64_t current;      // Current usage
    uint32_t flags;        // Behavior flags
};
 
#define RLIMIT_WARN_ONLY    0x01  // Log but don't enforce soft limit
#define RLIMIT_GRACEFUL     0x02  // Allow grace period for reduction
 
// Now policies can express:
// - Soft limit with warnings, hard limit enforced
// - Raise soft to hard for specific operations
// - Grace periods for temporary overages
// - Different enforcement strategies
 
// The mechanism doesn't decide which of these to use;
// it provides the primitives for policies to decide.

Principle 3: Policy Should Be Centralized

Keep policy decisions in identifiable, modifiable locations rather than scattered throughout code:

•Configuration files — Admins can change policy without code changes
•Policy modules — Well-defined interfaces for policy implementations
•Policy engines — Centralized decision points (like SELinux or AppArmor)
•Admin APIs — Runtime policy adjustment without restart

Principle 4: Provide Sensible Defaults

While mechanisms should be policy-neutral, systems need to work out of the box. Provide reasonable default policies that can be customized:

sensible_defaults.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
/**
 * Sensible Defaults with Override Capability
 */
 
// Mechanism: configurable scheduler
struct scheduler_config {
    uint32_t time_quantum_ms;      // Default: 10ms
    uint32_t priority_levels;      // Default: 140 (Linux)
    uint32_t rt_priority_levels;   // Default: 100
    bool     preemption_enabled;   // Default: true
};
 
// Default policy: balanced for interactive desktop
static struct scheduler_config default_config = {
    .time_quantum_ms = 10,
    .priority_levels = 140,
    .rt_priority_levels = 100,
    .preemption_enabled = true,
};
 
// Server policy: optimize for throughput
static struct scheduler_config server_config = {
    .time_quantum_ms = 100,    // Longer quantum = less switching
    .priority_levels = 140,
    .rt_priority_levels = 100,
    .preemption_enabled = false, // Voluntary preemption only
};
 
// Real-time policy: predictable latency
static struct scheduler_config rt_config = {
    .time_quantum_ms = 1,      // Very short quantum
    .priority_levels = 140,
    .rt_priority_levels = 100,
    .preemption_enabled = true,
};
 
// Selection at boot time via kernel parameter:
// sched.profile=server | desktop | realtime

Avoid Policy Leakage

A common mistake is letting policy assumptions leak into mechanisms. Each time you hardcode a number, timeout, or behavior decision in mechanism code, ask: 'Should this be configurable? Might different deployments need different values?' If the answer might be yes, make it policy.

Benefits of Policy-Mechanism Separation

Proper policy-mechanism separation provides substantial benefits throughout the system lifecycle:

1. Flexibility and Customization

•Different deployments use different policies without code changes
•Administrators tune behavior for specific workloads
•Vendors differentiate products by policy customization
•Research prototypes test new policies on production mechanisms

2. Maintainability and Evolution

•Mechanism bugs and policy bugs are isolated
•Mechanism can be optimized without affecting policies
•New policies can be added without mechanism changes
•Policy changes can be tested without mechanism risk

3. Testing and Verification

•Mechanisms can be tested with various synthetic policies
•Policies can be verified against policy language semantics
•Edge cases in mechanism implementation don't require policy understanding
•Formal verification is more tractable for separated components

4. Security Boundaries

•Security policy (what's allowed) is separate from enforcement (how it's checked)
•Policy can be audited by security experts without deep mechanism knowledge
•Different security policies for different contexts (development vs production)
•Centralized policy makes security review tractable

Separation Enables Independent Evolution
Component	Rate of Change	Separation Benefit
Hardware	Years	HAL mechanisms adapt; policies unchanged
Kernel mechanisms	Months	Optimizations don't affect policy correctness
Default policies	Weeks	Tune for new workloads without kernel rebuild
User policies	Days/Hours	Administrators adjust without reboot
Runtime decisions	Milliseconds	Policy engines react to changing conditions

The Testing Multiplier

Separation dramatically improves testing efficiency. If mechanism and policy are intertwined, N mechanisms and M policies require NxM tests. With separation, you need only N mechanism tests and M policy tests. For complex systems where N and M are large, this difference is enormous.

Modern Applications of Policy-Mechanism Separation

The policy-mechanism principle extends beyond traditional operating systems into modern infrastructure:

Containerization and Orchestration:

Docker and Kubernetes exemplify policy-mechanism separation at the infrastructure level:

kubernetes_policy_mechanism.yaml
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
# Kubernetes: Policy-Mechanism Separation
 
# MECHANISM: Kubernetes provides scheduling, scaling, networking
# POLICY: User defines desired state declaratively
 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  # POLICY: How many replicas (user decides)
  replicas: 3
  
  selector:
    matchLabels:
      app: web-app
  
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web
        image: nginx:latest
        
        # POLICY: Resource limits (user decides)
        resources:
          limits:
            cpu: "500m"
            memory: "128Mi"
          requests:
            cpu: "100m"
            memory: "64Mi"
 
---
# MECHANISM: HorizontalPodAutoscaler watches metrics and scales
# POLICY: When and how to scale (user decides)
 
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  
  # POLICY: Scaling boundaries
  minReplicas: 2
  maxReplicas: 10
  
  # POLICY: Scaling triggers
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
 
# The Kubernetes mechanisms (scheduler, autoscaler, controller)
# are unchanged. Users only specify policy.

Network Policy Engines:

Modern networking separates the network fabric (mechanism) from traffic handling (policy):

•Software-Defined Networking (SDN) — OpenFlow provides packet handling mechanisms; controllers define forwarding policies
•eBPF — Kernel provides program execution mechanism; programs define packet/syscall handling policies
•Network policies in Kubernetes — CNI provides networking mechanism; NetworkPolicy objects define access rules
•Service mesh — Envoy provides traffic handling mechanism; Istio policies define routing, retry, security

Security Frameworks:

Modern security systems embody clean policy-mechanism separation:

Security Policy-Mechanism Examples
System	Mechanism	Policy
SELinux	Type enforcement engine	Policy modules (targeted, MLS, etc.)
AppArmor	Path-based MAC enforcement	Profile files per application
Open Policy Agent	Rego evaluation engine	Rego policy definitions
OAuth 2.0	Token issuance/validation	Scopes, claims, consent flows
Capability systems	Capability check on access	Capability distribution policy

opa_example.rego

Rego

# Open Policy Agent: Policy as Code
 
# MECHANISM: OPA evaluates Rego policies against input data
# POLICY: Written in Rego language, separate from enforcement
 
package kubernetes.admission
 
# Policy: Deny privileged containers
deny[msg] {
    input.request.kind.kind == "Pod"
    container := input.request.object.spec.containers[_]
    container.securityContext.privileged == true
    msg := sprintf("Privileged containers are not allowed: %v", [container.name])
}
 
# Policy: Require resource limits
deny[msg] {
    input.request.kind.kind == "Pod"
    container := input.request.object.spec.containers[_]
    not container.resources.limits
    msg := sprintf("Container must have resource limits: %v", [container.name])
}
 
# Policy: Only allow approved registries
deny[msg] {
    input.request.kind.kind == "Pod"
    container := input.request.object.spec.containers[_]
    not starts_with(container.image, "mycompany.registry.io/")
    msg := sprintf("Images must come from approved registry: %v", [container.image])
}
 
# Same OPA mechanism enforces any policy written in Rego
# Policies can be updated without changing OPA itself

Policy as Code

Modern infrastructure increasingly represents policies as code—version controlled, tested, reviewed, and deployed like any other software. This is possible precisely because of policy-mechanism separation: the policy is data/code consumed by mechanisms, not embedded in mechanisms.

Summary: Policy vs Mechanism

We've explored the fundamental separation between policy and mechanism in operating system design. Let's consolidate the key insights:

Key Takeaways

•Mechanism is 'how'; policy is 'what' — Mechanisms provide capabilities; policies determine how those capabilities are used.
•Mechanisms should be policy-neutral — Don't embed specific decisions in mechanism code. Provide primitives that can support various policies.
•Policies should be changeable — Configuration, modules, or engines that can be modified without changing mechanisms.
•Separation enables independent evolution — Mechanisms can be optimized; policies can be tuned. Neither requires changing the other.
•Testing is more tractable — Test mechanisms independently of policies. Test policies against documented mechanism interfaces.
•Security benefits from separation — Centralized policy is auditable. Enforcement mechanisms can be verified separately.
•Modern systems embrace this principle — Kubernetes, SDN, policy engines, and infrastructure-as-code all embody policy-mechanism separation.

Module Conclusion:

Throughout this module, we've explored five fundamental tradeoffs in operating system design:

Efficiency vs Convenience — Balancing raw performance against ease of use
Flexibility vs Simplicity — Choosing between customizability and maintainability
Security vs Usability — Protecting users while keeping systems accessible
Portability Considerations — Trading platform independence for optimization
Policy vs Mechanism — Separating what should happen from how it happens

These tradeoffs are not isolated—they interact. A flexible mechanism supports multiple policies. A portable design may sacrifice efficiency. Security measures impact convenience. Understanding these interactions is the hallmark of system design mastery.

No operating system gets all these tradeoffs 'right' in an absolute sense, because 'right' depends on context. A real-time system, a cloud server, and a smartphone make different choices appropriate to their requirements. The goal isn't to find perfect answers but to understand the tradeoffs deeply enough to make informed decisions.

Module Complete

You have completed the Design Goals and Tradeoffs module. You now understand the fundamental tensions that shape every operating system—tensions that don't have universal solutions, only context-appropriate balances. This understanding will inform your evaluation of existing systems and your design of new ones. As you study specific OS components in subsequent chapters, you'll recognize these tradeoffs operating at every level of the system.