Operating System Architectures

Дата канвертавання19.04.2016
Памер50.47 Kb.

Operating System Architectures

[Silberschatz ch2]

  • OS as virtual machine to users

  • Mechanisms and Policies

Mechanisms Policies
How basic facilities should be what specifics to be done (flexibility)
time construct for CPU protection how long the timer for a user?
no change over place and time change (only redfine certain param.)
giving priority priority values I/O vs. CPU bound

* Microkernel: mechanism/policy separation to extreme

* small or basic set of primitive building blocks (policy free)

  • Two Key Architectures: Monolithic/Microkernels

Monolithic Microkernel
massive, undifferentiated, intractable only basic abstractions (mechanism)

(addr map, drivers, ipc, interrupts, switch)

single addr. space, efficiency extensibility, emulation (VM), secure
lack of structure-> layering, OO modularity, open distri. System
Unix, Windows (XP) Mach, Chorus

[Note: XP embodys basic OO mechanism with access-interface defined]

  • Hybrid Approaches

Mach and Chorus (microkernel) improved version

initially developed by running servers as user processes which

communicate with kernel via interrupts/messages

Performance considerations: servers can be loaded dynamically

into kernel or user address space, client interactions via same ipc calls.

Can debug a server at user level, and then later run it inside the kernel addr. for performance (but then may threatens integrity – if still has bugs)

SPIN (’95):

Finesses the problem of trading off efficiency for protection by employing type-safe language facilities (modula-3) for protection.
Kernel and dynamically loaded modules grafted on to kernel (single addr. space) – using type-safe language for mutual protection (access only given by a reference)
Minimize dependencies between system modules by choosing an event-based (net., timer, page fault) model for interactions between modules

System components register themselves for handlers for events

2nd generation microkernel design
Forces dynamically loaded system modules executed in user space (but optimize IPC to offset the costs)
Offloads kernel complexity: management of addr space in user-level servers


Employing user-level libraries (instead of user-level servers)

to supply function extensions

Only Protected allocation of extremely low-level resources such as disk blocks.
Expects all other resource management functionality (even file system) to be linked in to applications as libraries.
Machine hardware allocated between multiple virtual machines

(virtual hardware images), each running a separate OS instance

IBM 370VM.

Project Xen (2003) developed virtual machine monitor (for PC)

A software layer between HW (with host PS) and commodity OS

Such as Linux, Windows,

Commercial VMWare

  • Dynamically loadable kernel modules: Disadvantages

Size: module management (using non-pageable kernel memory space)

Complexity of kernel bootstrap
Modules loaded from disk (driver needed to access disk must be loaded first)
Manage bootstrap requiring extra work

  • Loadable kernel modules: Choices

How often: modules (drivers) to be used – on demand?

Kernel to be built – usable on large variety of machines or single machine?

  • Loadable kernel modules access kernel symbols:

Only a fixed set of entry points made available to kernel modules.

kernel module can not invoke arbitrary code with kernel

and interfere with kernel execution

that the kernel interactions at controlled points (invariants)
Limited number of symbols can be accessable to kernel module.

(loss in flexibility and performance because some details of kernel are hidden from the module)

  • Shared Libraries: advantages


Protection to prevent bug in kernel

less kernel memory

calling faster – since calling kernel involves syscall
loaded as needed, upgrade is easy- no system down

  • Shared Libraries: drawbacks

Some code unsuitable in shared library

Low level dev drivers or file systems
Services shared around the entire system better implemented in kernel

if performance critical.

Otherwise if it is running as separate process/communicating with it

through IPC (requiring two context switches for each requested)

Security/Privilege Limitation
Shared lib. runs with privilege of process calling the lib

Can not directly access resources inaccessible to calling process

Service provided requires any privilege outside a normal process

or data managed by lib. needs to be protected from normal user process - ?

  • Virtual Machines

Layered approach to its logical conclusion

Treats HW and OS kernel as though they are all hardware

Provides interface identical to underlying bare hardware

Complete protection of system resources (isolated) – OS development


Introduction to Linux Kernel

  • Monolithic (much from Micro-kernel)

Dynamically loadable kernel module

  • SMP support

  • Thread support: process/thread, shared/partial shared (clone)

  • Processor affinity

  • Implement only that makes real-sense/applications

  • Kernel memory not pageable

  • Kernel version notation: 2.5 develop / 2.6 stable (2.6.1 patch)

  • Kernel different from user-space applications

No libc (not linked) – speed and size issue

many functions implemented inside the kernel: printk
Source in GNU C (not ANSI C): some extensions

inline function, inline assembly

No memory protection, kernel memory not pageable
No (Easy) use of Floating Point (no easy way to trap itself)
Small fixed-size stack (user stack can be large, dynamic)
More susceptible to race condition (synchronization/concurrency)

preemptive multitasking/SMP/interrupts

More important on portability
Architecture indep. C and architecture dep. Part on kernel source tree
Remain endian neutral, be 64-bit clean, no assumption on word/page size

  • Linux on various hardware platform and needs to be portable to different CPU and memory architectures – How is kernel designed and implemented?

  1. Keep as much as possible on common code

  1. Provide a clean way of defining architecture-specific properties and code

Two separate subdirectory hierarchies for each hardware architecture

Code for the architecture (syscalls interface, interrupts)
C header files (descriptive of the architecture): type definition and macro

hiding architecture difference – word/page size, endian order conversion

Process Management

  • Manipulating Current Process States

  • Process Context

User Space

System Calls -> kernel space (on behalf of process) – process context

[Current macro is valid]

Interrupt context

  • Process Family Tree

init init_task pid=1 // starts in last step of boot

reads system initscripts – completing boot process
Tree: parent, children, siblings
task list is circular doubly linked list
macros: next_task (task), prev_task (task), for_each_process(task)

  • Process creation - fork, vfork, clone, exec

fork: copy, But own pid, ppid, pending signals, copy-on-write

  • Copy On Write (COW)

Share addr. space (data marked: if written, dup)

Delay copying until actually written (exec case, will never)
Only overhead of fork: dup of parent page tables, creation of process descriptor

  • Fork

Implement fork via clone syscall

fork, vfork,_clone library calls : all invoke clone syscall
do-fork (in kernel/fork.c) -> copy_process
dup_task_struct: new kernel stack, thread_info, task_struct
check resource limit
process descriptor (shared, or adjusted – initial values)
Task_UNINTERRUPTIBLE (ensure - not running yet)
Copy_flags (update flags in task_struct)
Based on flags passed to clone
Dup/share open files, filesystem info. Signal handlers, addr. space

Remaining time slice split between parent/child

  • Vfork

Same as fork except: page table entries not copied

Implemented via a special flag to clone syscall
Child executes as sole thread in parent addr. space
Parent blocked till child exec/exit
Child not allowed writing to addr. space
Because: COW and child run first semantics
The only benefit of vfork is: not copying parent page table entries

No concept of thread

Implement as process
Other OS: threads are an abstraction to provide a lighter/quicker execution unit

One process descriptor (shared) - in turn pointing to different threads (indiv.)

Linux simply a manner of sharing resources between processes
Simply several processes and several task_struct structures (and share some resource)

  • Process Termination

exit () syscall or implicitly, do_exit()

task_struct : EXITING
remove kernel timer, release mm_struct, exit_sem
exit_files, fs, namespace, sighand (ref. count)
set exit code
exit_notify signal to parent
reparent any of the task’s children to another thread in their thread group

or to init process.

call schedule()
The only memory it occupies: kernel stack, thread_info, task_struct

(freed when parent wait for – completion)

wait family are implemented via a single wait4() syscall by parent
AT END: release_task (free all resources)

  • Parentless Task

Parent exit before its children -> reparent child tasks

To either another process in the current thread group or

If fails, the init process.

do_exit -> notify_parent ->forget_original_parent

База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка