Operating System Services

Operating System Services

• Operating systems let programs execute and services to be provided to programs and users.
• OS services provide helpful functions to the user.
• User interface exists in almost all operating systems.
• User interface varies and can include Command-Line (CLI), Graphics User Interface (GUI), or Batch.
• A system must load a program into memory and run that program, ending on completion or if errors occur.
• Running programs can require I/O, involving file or I/O device use.
• Programs need to read and write files and directories, create and delete items, search, list file data, and handle permissions related to file-system manipulation.
• Processes may exchange information on the same computer or via network.
• Communications completed via shared memory or through message passing done by the OS.
• An OS has to stay aware of possible errors that may occur in CPU and memory hardware, in I/O services, and in the user program.
• The OS has to respond to errors to ensure the system is correct and stays consistent
• Debugging helps developers use the system efficiently

Ensuring Efficient Operation of System

• OS functions ensure efficient function by sharing resources between multiple users or running jobs
• Resources like CPU cycles, memory, and file storage require special allocation code
• I/O devices may have general request and release code.
• Accounting tracks which users use what computer resources and how much of each.
• Protection and security allows owners of info that is stored on a computer system to control the use of it. Concurrent processes should not interfere with each other
• Access to system resources is controlled through Protection.
• User authentication protects security from outsiders and defends external I/O devices from invalid access attempts.
• Protected and secure systems require precautions via methodical institution; a chain is only as strong as its weakest link.

User Operating System Interface

• Command Line Interface (CLI) or a command interpreter are allowed to provide a direct command entry
• CLIs are sometimes implemented in the kernel or by programs
• Multiple types of CLIs are implemented by shells
• Commands are fetched by the user and executed. There can be built-in command or just program names.
• Adding new features may not require shell modification for CLIs

GUI

• The user friendly desktop provides an interface
• Mouse, keyboards, and monitors are typically used
• Icons stand for files, programs, functions etc..
• There are various mouse buttons that cause actions.
• GUI's can provide info, options, execute a function or open directories
• Xerox PARC created the GUI
• Many systems now include both CLI and GUI interfaces
• CLI "command" shell included in Microsoft Windows GUI
• The Aqua GUI interface with UNIX kernel is present in Apple Mac OS X, with shells available.
• Solaris has CLI with optional Java Desktop GUI (KDE)

System Calls

• Provide programming interface to OS services
• Usually written in C or C++
• Programs mostly access the system via the API (Application Program Interface
• Behind the scenes, functions that setup an APIs invoke system calls on behalf of programmers
• Interface to OS services (System call) vs interface to the system calls for ease of programmers (API)
• Windows’ CreateProcess initiates the NTCreateProcess system call in the Windows kernel
• User interacts with program which interfaces with APIs which uses system calls to access OS which interfaces with the H/W

Common APIs

• Win32 API for Windows
• POSIX(Portable Operating System Interface) API for POSIX based systems i.e. all linux, UNIX and mac
• Java API for JVM (Java Virtual Machine)

Why Use APIs Instead of System Calls?

• Program portability: programs with an API may compile and run on any system with the same API
• Ease of use: the programmer is provided with an API because system calls can be more detailed and difficult to work with

System Call Implementation

• Each implementation has an associated number
• Indexed based on system-call interface in a table that it maintains
• The interface invokes the system call in OS kernel, returning it back to the user.
• Programmers only need to obey the API and understand what the OS will do. Details are hidden
• Managed by run-time support library; A set of functions included with the compiler.

System Call Parameter Passing

• Extra info is sometimes needed
• Exact details vary according to OS
• Three general methods
• Simplest method is to pass in registers. Some cases may need more parameters
• Parameters can be stored in a block, or table, in memory. The address of the block can then be passed as a parameter in the register. This implementation is used by Linux and Solaris
• The stack method places or pushes, parameters onto a stack
• Block and stack methods wont limit parameter length or number

Types of System Calls

• Process control
• End, abort, load, execute, create/terminate process, set/get process attributes, wait for time/event, signal event, allocate/free memory
• File Management
• Create/delete file, open/close file, read/write/reposition file, set/get file attributes
• Device management
• Request/release device, read/write/reposition device get/set device attributes, attach/detach device.
• Information maintenance
• Get/set time or date, get/set system data, get/set process, file, or device attributes
• Communications
• Create/delete communication connection, send/receive messages, transfer status information, attach/detach remote devices

System Programs

• Provide a convenient environment to allow development and execution
• Divided into:
  • file manipulation, status information, file modification, language support, program loading and execution, communications, and applications programs.
• In general, system programs define how users experience the OS, not the system calls themselves.

System Program Functions

• Provide a convenient environment for program development and execution; some simple user interfaces for system calls and others more complex
• File Management handles manipulation of files and directories; creation, deletion, copying, renaming, printing, dumping, and listing
• Status: Gives the system's date, time, RAM amount, free disk space, and number of users
• Status: Offers detailed performance, logging, and debugging information
• Programs format and print the output to the terminal or any output devices.
• Registry implementation assists in configuration by storing and retrieving data.
• Text editors modify/create files.
• Special commands locate certain file contents or convert the text.
• Compilers, assemblers, debuggers, and interpreters are available for programming language assistance.
• Absolute loaders relocatable loaders, linkage editors, overlay loaders, debugging systems are used for loading and execution
• Mechanisms for building virtual connections between users, systems, and processes are provided.
• Users can use each other’s screens, browse the web, remotely log in, send messages, and transmit files.

Design and Implementation

• Operating System Design and Implementation not "solvable," but there are some approaches that have proven successful
• Structure of the system is different from OS to OS
• Starts by defining goals and specifications using the hardware and type of system i.e. mobile device, or distributed system.
• Goals are based on user and system metrics
• User goals: Easy, safe, reliable, convenient, and fast
• Systems goals: Design, implement, and maintenance which is be flexible, reliable, error-free, and efficient
• Key point is to separate policy, what will be done, and mechanism, how will it be be done.
• Mechanisms are in charge of how something takes place, policies decide WHAT will happen.
• Example: the CPU is protected by a timer that decides the usage timing through policy.
• Policy and mechanisms allow for maximum flexibility if policy decisions are to be changed later.

Implementation Variation

• OSs used to be written in assembly language
• Then came system programming languages like Algol and PL/1
• C and C++ are now used
• Lowest levels use assembly, main body uses C, and system programs use Perl or Python
• Use of a High level language to port to other platforms
• Fast Production, compact code, and easy to debug code for the user.
• OS can be emulated if the original hardware isnt built yet

OS Structures

• Simple
• Monolithic
• Layered
• Microkernel
• and Modular

Simple Structure

• MS-DOS was written to provide the maximum amount of functionality within the least amount of space
• It is not divided into modules.
• Interfaces and levels of functionality not separated
• App programs can directly access H/W
• All layers have access to H/W, not layered.
• Due to the H/W interactions, it is not well protected, structured, or defined
• No dual mode support because it runs on the Intel 8088

UNIX Structure

• Limited by Hardware functionality, the original operating system had limited structure
• Two separable part (OS):
• Systems programs
• Kernel
  • Includes call interface, everything below everything hardware
  • File system, memory system, and CPU scheduling. Large amounts of functions for single level

Layered Approach

• Operating system divided into layers (levels)
• Layer 0 is hardware and final layer is the user interface.
• Each layer uses functions and services from the lower level layers.
• Inner layers hide details from the outer layers for easier debugging
• If there is an error in one layer it may not influence the other errors.
• 2 problems are layer difficulty definition, and layer hierarchy, and changing the system parameters during a system call, adding overhead

Mach Microkernel

• Removes non-essential kernel services as system applications (makes as small and efficient as possible)
• Mac OSX's Darwin kernel is an example
• The user modules communicate with the kernel to allow messages to pass through, allowing extendability, architecture portability, and reliability
• There is a performance overhead for both user and kernel space: Window NT, NT4.0, and XP are detriments

Modules

• Kernel modules utilize the most current OS
• Object oriented
• Each element is unique, but they communicate through known interfaces; they’re loadable as needed within the kernel
• Similar to layers but flexible like Linux and Solaris

Virtual Machine Idea

• Abstract H/W of one computer into several execution environments
• Approaches in logical way with h/w and OS kernel as all H/W
• Creates illusion in the operating system as a processor
• They exist as the guest copy

Virtual Machines History and Benefits

• They debuted in 1972 on the IBM mainframes commercially
• They provide different execution environments, but can share the same H/W using protection
• Controlled sharing of files is permitted
• They commute with each other with other physical systems via networking
• Test systems for development and consolidation with low use systems

Paravirtualization

• Presents guest with system that's similar but not identical to H/W with changes (guest)
• Solaros 10 applications sometimes run these

Implementations

• Difficult to design needing a duplicate (must have precise timing) running in user code but creates virtual user mode and virtual kernel modes
• Needs certain support i.e. AMD who offers host and guest modes

Debugging

• Finding and fixing errors
• OS can be used in file logs with error reports
• Failure applications that capture memory (core dump) can use OS which contain kernel memory
• Performance can be upgraded, Kernighan suggest if the code is overly smart, it wont debug correctly and will require live instrumentation such as Free BSD, Solaris,and Mac OX that are running correctly
• Probes capture the state data and when the code is initiated and sent to consumers of those probes

OS Generalization

• Configured with other class machines for specified hardware or software with certain configuration
• SysGen can obtain the information concerning what is going to be used, memory, CPU, and devices interfaced
• Booting loads the kernel
• Bootstrap program is a code that is stored in ROM that will locate and load the kernel so it can start in memory for Execution

System Boot

• OS must make the H/W available so it it can start it
• Small code piece that runs bootstrapper loader and where to save for memory (kernel)
• Sometime used in 2 stage system, first with bootblock,then the loading of the bootstrapper loader
• First power on with executions and save for flash card to hold the code
• Then used with the firmware