OS Design Structure Abstraction System Call

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 37

OS Design issues, Abstraction, Structure

of OS and System Calls

Dr. N.Nalini
SCOPE
VIT
Operating System Design Issues
• The important issues related to Operating system
are
– transparency, flexibility, reliability, performance,
scalability, naming, replication, synchronization,
security.
Operating System Design Issues
Transparency
• Multiple Computers are used but the user gets a view of only single system being used. Makes the
network invisible to user/applications.
Flexibility
• Flexible operating systems are taken to be those whose designs have been motivated to some degree
by the desire to allow the system to be tailored, either statically or dynamically, to the requirements of
specific applications or application domains.
Reliability
• In general, reliability is the ability of a person or system to perform and maintain its functions in routine
circumstances, as well as hostile or unexpected circumstances.
• Reliability is generally considered important by end users. Not all companies making operating systems
have a similar standard. Even among operating systems where reliability is a priority, there is a range of
quality.
• Also, an operating system may be extremely reliable at one kind of task and extremely unreliable at
another. Current operating systems have two characteristics that make them unreliable and insecure.
• They are huge and have very poor fault isolation.
Operating System Design Issues
Performance
• The performance of computer hardware typically increases monotonically with time.
Even if the same could be said of software, the rate at which software performance
improves is usually very slow compared to that of hardware.
• In fact, many might opine that there is plenty of software whose performance has
deteriorated consistently with time.
• Moreover, it is rather difficult to establish an objective performance metric for
software as complex as an operating system: a "faster OS" is a very subjective, context
dependent phrase.
Operating System Design Issues
Scalability
• Scalability is a desirable property of a system, a network, or a process, which indicates
its ability to either handle growing amounts of work in a graceful manner, or to be
readily enlarged.
• A system whose performance improves after adding hardware, proportionally to the
capacity added, is said to be a scalable system.
Naming
• The resources in a distributed system are spread across different computers and a
naming scheme has to be devised so that users can discover and refer to the resources
that they need.
• An example of such a naming scheme is the URL (Uniform Resource Locator) that is
used to identify WWW pages.
– If a meaningful and universally understood identification scheme is not used then many of these
resources will be inaccessible to system users.
Operating System Design Issues
Replication
• Replication is one of the oldest and most important topics in the overall
area of distributed systems. Whether one replicates data or computation,
the objective is to have some group of processes that handle incoming
events.
• If we replicate data, these processes are passive and operate only to
maintain the stored data, reply to read requests, and apply updates.
When we replicate computation, the usual goal is to provide fault-
tolerance.
Operating System Design Issues
Synchronization
• Processes requires coordination to achieve synchronization. Process must reach a
common synchronization point before they can continue.
• A process must wait for a condition that will be set asynchronously by other
interacting processes to maintain some ordering of execution. Concurrent processes
must have mutual exclusion when accessing a critical shared resource.
Security
• Authentication: Clients, Servers and messages must be authenticated
• Authorization: Access control has to be performed across a physical network with
heterogeneous components under different administrative units using different
security models.
OS Abstraction
• The operating system provides a layer of abstraction between the user and
the bare machine. Users and applications do not see the hardware directly, but view
it through the operating system.
• This abstraction can be used to hide certain hardware details from
users and applications. Thus, changes in the hardware are not seen by the user (even
though the OS must accommodate them).
• This is particularly advantageous for venders that want offer a consistent OS interface
across an entire line of hardware platforms.
• Another way that abstraction can be used is to make related devices appear the same
from the user point of view.
• For example, hard disks, floppy disks, CD-ROMs, and even tape are all very different
media, but in many operating systems they appear the same to the user.
• Abstraction
– Hide the implementation details of a
component
Abstraction
– Freedom to modify the implementation without
affecting other underlying modules Component -1
– Ex: int add(int a, int b) { Interface
return a + b; // Implementation details
} Abstraction
• Interface Component -2
– To hide the details of lower level components
– To enable the communication / data passing
between the components without knowing Take away:
details of their implementation
– Ex: printf(“%d, %d”, add(5,10), add(10,10)) If you introduce an interface,
you want to hide the
implementation details
below it
Operating System Structure
• General-purpose OS is very large program
• Various ways to structure ones
– Simple structure – MS-DOS
– Monolithic Structure– Traditional/old UNIX
– Modular - Linux
– Layered – an abstraction -Unix
– Microkernel – Mach
SIMPLE STRUCTURE
• It is the most straightforward operating system
structure, but it lacks definition and is only
appropriate for usage with tiny and restricted
systems.
• The interfaces and levels of functionality are not well
separated. MS-DOS is an example of such operating
system.
• In MS-DOS application programs are able to access
the basic I/O routines.
• These types of operating system cause the entire
system to crash if one of the user programs fails.
Simple structure
Advantages of Simple structure:
• It delivers better application performance because of the few interfaces between the
application program and the hardware.
• Easy for kernel developers to develop such an operating system.

Disadvantages of Simple structure:


• The structure is very complicated as no clear boundaries exists between modules.
• The entire operating system breaks if just one user program malfunctions.
• Since the layers are interconnected, and in communication with one another, It does
not enforce data hiding in the operating system.
• The operating system's operations are accessible to layers, which can result in data
tampering and system failure.
Monolithic Structure
• The monolithic operating system is often
referred to as the monolithic kernel.
• Monolithic single-kernel OS approach
– written as a single program ( no modules
at all)
• kernel or monolithic kernel - Original
UNIX
• Multiple programming techniques such as
batch processing and time-sharing increase a
processor's usability.
• Working on top of the operating system and
under complete command of all hardware,
the monolithic kernel performs the role of a
virtual computer.
Monolithic Structure
Advantages of Monolithic Structure:
• Because layering is unnecessary and the kernel alone is responsible for managing all
operations, it is easy to design and execute.
• Due to the fact that functions like memory management, file management, process
scheduling, etc., are implemented in the same address area, the monolithic kernel
runs rather quickly when compared to other systems.
• Utilizing the same address speeds up and reduces the time required for address
allocation for new processes.
Disadvantages of Monolithic Structure:
• The monolithic kernel's services are interconnected in address space and have an
impact on one another, so if any of them malfunctions, the entire system does as well.
• It is not adaptable. Therefore, launching a new service is difficult.
Traditional UNIX System Structure
Beyond simple but not fully layered
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
Layered Approach
• The functionalities of each layer are separated in this method, and abstraction is also
an option.
• Because layered structures are hierarchical, debugging is simpler, therefore all lower-
level layers are debugged before the upper layer is examined.
• As a result, the present layer alone has to be reviewed since all the lower layers have
already been examined.
• The main disadvantage of this structure is that at each layer, the data needs to be
modified and passed on which adds overhead to the system.
• Moreover careful planning of the layers is necessary as a layer can use only lower level
layers.
• UNIX is an example of this structure.
Layered Approach
Advantages of Layered structure:
• Layering makes it easier to enhance the operating system as implementation of a layer
can be changed easily without affecting the other layers.
• Work duties are separated since each layer has its own functionality, and there is
some amount of abstraction.
• It is very easy to perform debugging and system verification.
Disadvantages of Layered structure:
• In this structure the application performance is degraded as compared to simple
structure.
• It requires careful planning for designing the layers as higher layers use the
functionalities of only the lower layers.
Different Variations
1. Allow modules at layer n to call
only the modules in the next lower
layer n-1

2. allow modules at layer n to call


modules at any of the lower layers
( n-1, n-2, and so on).

3. allow level n modules to interact


with other level n modules
Microkernels
• This structure designs the operating system by removing all non-essential
components from the kernel and implementing them as system and user programs.
This result in a smaller kernel called the micro-kernel.
• Advantages of this structure are that all new services need to be added to user
space and does not require the kernel to be modified.
• Thus it is more secure and reliable as if a service fails then rest of the operating
system remains untouched.
– Mach is an example of microkernel . Mac OS X kernel (Darwin) partly based on Mach
• Each Micro-Kernel is created separately and is kept apart from the others.
– As a result, the system is now more trustworthy and secure.
• If one Micro-Kernel malfunctions, the remaining operating system is unaffected and
continues to function normally.
Micro kernel Approach
Advantages of Micro-kernel structure:
• It makes the operating system portable to various platforms.
• As microkernels are small so these can be tested effectively.
• Due to the isolation of each Micro-Kernel, it is reliable and
secure.
Disadvantages of Micro-kernel structure:
• Increased level of inter module communication degrades system
performance.
– Performance overhead of user space to kernel space communication
– Makes a microkernel OS run more slowly due to context switching and not yet resolved
Modules
• It is considered as the best approach for an OS. It involves designing of a modular
kernel.
• The kernel has only set of core components and other services are added as
dynamically loadable modules to the kernel either during run time or boot time.
• It resembles layered structure due to the fact that each kernel has defined and
protected interfaces but it is more flexible than the layered structure as a module can
call any other module. Many modern operating systems implement loadable kernel
modules (LKMs)
– 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.
Linux System Structure
Monolithic plus modular design
Hybrid Systems
• Most modern operating systems are 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)
System Calls
• Programming interface to the services provided by the OS
• A system call is how a program requests a service from an operating
system's kernel.
• Typically written in a high-level language (C or C++)
• Mostly accessed by programs via a high-level Application
Programming 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)
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 is associated with each
system call
– System-call interface maintains a table
indexed according to these numbers
• The system call interface invokes the
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
Standard C Library Example
• C program invoking printf() library call, which calls write() system call
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
– create process, terminate process
– end, abort
– load, execute
– 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 (Cont.)
• 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

You might also like