Chapter 2: System Structures: Silberschatz, Galvin and Gagne ©2013 Operating System Concepts - 9 Edition

Chapter 2: System Structures
Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013
System Calls
 Programming interface to the services provided by the OS
 Typically written in a high-level language (C or C++)
 Mostly accessed by programs via a high-level Application Program

Interface (API) rather than direct system call use
 Three most common APIs are Win32 API for Windows, POSIX API
for POSIX-based systems (including virtually all versions of UNIX,
Linux, and Mac OS X), and Java API for the Java virtual machine
(JVM)
 Why use APIs rather than system calls?
(Note that the system-call names used throughout this text are
generic)
Operating System Concepts – 9th Edition 2.2 Silberschatz, Galvin and Gagne ©2013
Example of System Calls
 System call sequence to copy the contents of one file to another file
Example of Standard API
System Call Implementation
 Typically, a number associated with each system call
 System-call interface maintains a table indexed according to
these numbers
 The system call interface invokes intended system call in OS kernel

and returns status of the system call and any return values
 The caller need know nothing about how the system call is
implemented
 Just needs to obey API and understand what OS will do as a
result call
 Most details of OS interface hidden from programmer by API
 Managed by run-time support library (set of functions built into
libraries included with compiler)
API – System Call – OS Relationship
System Call Parameter Passing
 Often, more information is required than simply identity of desired
system call
 Exact type and amount of information vary according to OS and
call
 Three general methods used to pass parameters to the OS

 Simplest: pass the parameters in registers
 In some cases, may be more parameters than registers
 Parameters stored in a block, or table, in memory, and address of
block passed as a parameter in a register
 This approach taken by Linux and Solaris
 Parameters placed, or pushed, onto the stack by the program
and popped off the stack by the operating system
 Block and stack methods do not limit the number or length of
parameters being passed
Parameter Passing via Table
Types of System Calls
 Process control
 end, abort
 load, execute
 create process, terminate process
 get process attributes, set process attributes
 wait for time
 wait event, signal event
 allocate and free memory
 Dump memory if error

 Debugger for determining bugs, single step execution
 Locks for managing access to shared data between processes
Types of System Calls
 File management
 create file, delete file
 open, close file
 read, write, reposition
 get and set file attributes
 Device management
 request device, release device
 read, write, reposition
 get device attributes, set device attributes
 logically attach or detach devices
Types of System Calls (Cont.)
 Information maintenance
 get time or date, set time or date
 get system data, set system data
 get and set process, file, or device attributes
 Communications
 create, delete communication connection
 send, receive messages if message passing model to host name or
process name
 From client to server
 Shared-memory model create and gain access to memory regions
 transfer status information
 attach and detach remote devices
Types of System Calls (Cont.)
 Protection
 Control access to resources
 Get and set permissions
 Allow and deny user access
Examples of Windows and
Unix System Calls
Standard C Library Example
 C program invoking printf() library call, which calls write() system call
Operating System Design
and Implementation
 Design and Implementation of OS not “solvable”, but some

approaches have proven successful
 Internal structure of different Operating Systems can vary widely
 Start by defining goals and specifications
 Affected by choice of hardware, type of system
 User goals and System goals

 User goals – operating system should be convenient to use, easy
to learn, reliable, safe, and fast
 System goals – operating system should be easy to design,
implement, and maintain, as well as flexible, reliable, error-free,
and efficient
Operating System Design and
Implementation (Cont.)
 Important principle to separate

Policy: What will be done?
Mechanism: How to do it?
 Mechanisms determine how to do something, policies decide what will

be done
 The separation of policy from mechanism is a very important
principle, it allows maximum flexibility if policy decisions are to be
changed later
 Specifying and designing OS is highly creative task of software

engineering
Implementation
 Much variation
 Early OSes in assembly language
 Then system programming languages like Algol, PL/1
 Now C, C++
 Actually usually a mix of languages
 Lowest levels in assembly
 Main body in C
 Systems programs in C, C++, scripting languages like PERL,
Python, shell scripts
 More high-level language easier to port to other hardware
 But slower
 Emulation can allow an OS to run on non-native hardware
Operating System Structure
 General-purpose OS is very large program
 Various ways to structure one as follows
1. Simple Structure
2. Layered Approach
3. Microkernel Approach
4. Module Based Approach
5. Hybrid Systems
1. Simple Structure
 I.e. MS-DOS – written to provide
the most functionality in the least
space
 Not divided into modules
 Although MS-DOS has some
structure, its interfaces and
levels of functionality are not
well separated
 Drawback : Difficult to Implement
and Maintain and also not
Scalable
2. Layered Approach
 The operating system is
divided into a number of
layers (levels), each built
on top of lower layers.
The bottom layer (layer 0),
is the hardware; the
highest (layer N) is the
user interface.
 With modularity, layers are

selected such that each
uses functions
(operations) and services
of only lower-level layers
2. Layered Approach ….
 Advantages:
1. Operating System is decomposable and therefore effects
separation of concerns and different abstraction levels.
2. Allows good maintenance, where you can make changes
without affecting layer interfaces
 Disadvantages:
1. It is difficult to exactly assign of functionalities to the correct
and appropriate layer
2. Because of having too many layers, performance of the
system is degraded
3. Microkernel System Structure
 Key Features:
1. Essential and Non-Essential Services/Components of Operating System are
Separated
2. Non-Essential Services/Components are Implemented as system and user-level
programs
3. Essential/Key Services are implemented as separate module known as
microkernel [Smaller Kernel]
4. Mach Operating example of microkernel
5. Communication takes place between user modules using Message Passing
6. Client/User Level Program Interact/communicate with servers indirectly by
exchanging messages via microkernel [See Next Slide]
3. Microkernel System Structure ….
Application File Device user

Program System Driver mode
messages messages
Interprocess memory CPU kernel

Communication managment scheduling mode
microkernel
hardware
3. Microkernel System Structure ….
 Benefits:
 Easier to extend a microkernel
 Easier to port the operating system to new architectures
 More reliable (less code is running in kernel mode)
 More secure-If a service fails rest of the OS remain untouched
 Detriments:
 Performance overhead of user space to kernel space communication
4. Modules Based Approach
 Most modern operating systems implement loadable kernel modules
 Uses object-oriented approach
 Each core component is separate
 Each talks to the others over known interfaces
 Each is loadable as needed within the kernel
 Overall, similar to layers but with more flexible

 Linux, Solaris, etc
Solaris Modular Approach
5. Hybrid Systems
 Most modern operating systems actually not one pure model
 Hybrid combines multiple approaches to address performance, security,
usability needs
 Linux and Solaris kernels in kernel address space, so monolithic, plus
modular for dynamic loading of functionality
 Windows mostly monolithic, plus microkernel for different subsystem
personalities
 Apple Mac OS X hybrid, layered, Aqua UI plus Cocoa programming
environment
 Below is kernel consisting of Mach microkernel and BSD Unix parts,
plus I/O kit and dynamically loadable modules (called kernel
extensions)

Chapter 2: System Structures: Silberschatz, Galvin and Gagne ©2013 Operating System Concepts - 9 Edition

Uploaded by

Copyright:

Available Formats

Chapter 2: System Structures: Silberschatz, Galvin and Gagne ©2013 Operating System Concepts - 9 Edition

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 2: System Structures: Silberschatz, Galvin and Gagne ©2013 Operating System Concepts - 9 Edition

Uploaded by

Copyright:

Available Formats

Chapter 2: System Structures

 Typically written in a high-level language (C or C++)

 Mostly accessed by programs via a high-level Application Program

 Why use APIs rather than system calls?

 The system call interface invokes intended system call in OS kernel

 Three general methods used to pass parameters to the OS

 Dump memory if error

 Design and Implementation of OS not “solvable”, but some

 Internal structure of different Operating Systems can vary widely

 Start by defining goals and specifications

 Affected by choice of hardware, type of system

 User goals and System goals

 Important principle to separate

 Mechanisms determine how to do something, policies decide what will

 Specifying and designing OS is highly creative task of software

 With modularity, layers are

Application File Device user

Interprocess memory CPU kernel

 Overall, similar to layers but with more flexible

You might also like