Chapter 2: Operating-System Structures Modified Considerably by your Instructor

Chapter 2: Operating-System StructuresChapter 2: Operating-System Structures

Modified Considerably by your Instructor

2.2 Silberschatz, Galvin and Gagne ©2005Operating System Concepts

Chapter 2: Operating-System StructuresChapter 2: Operating-System Structures

Chapter 2.1 – First Part Operating System Services User Operating System Interface System Calls Types of System Calls

Chapter 2.2 – Second Part System Programs Operating System Design and Implementation Operating System Structure Virtual Machines Operating System Generation System Boot


0. Introductory Remarks - Objectives0. Introductory Remarks - Objectives

At a rather superficial level yet, we will overview some of the main operating system structures.

Operating Systems can be viewed from a number of perspectives.

Perspectives center around the

Services operating systems provide, and

how they provide these services.

(These services are many and varied.)

Interface provided - to those using the computing system (programmers and users)

Components and interconnections provided by operating systems.

We will look at all three in this chapter but reserving a much more detailed look for later chapters.


1. Operating System 1. Operating System ServicesServices User services include:

User interface - All operating systems have a user interface (UI)

Will either be a Command-Line (CLI), Graphics User Interface (GUI), Batch

Many kusers are more ‘used to’ one form than another.

– CS people; Information Systems users; IT; engineers…

Each have advantages and disadvantages; adherents and opponents.

Program execution - The system must be able to load a program into memory, run that program, terminate execution, either normally or abnormally

I/O operations - Running programs may require I/O => involve file or I/O device.

Because I/O operations involved shared devices, these devices and the programs / users who access them must be protected.

File-system manipulation - The file system is of particular interest.

User services include the ability to read and write files and directories, create and delete them, search them, list file Information, and manage permissions / access in a wide variety of ways.


Operating System Services (Cont.)Operating System Services (Cont.) Other operating-system services helpful to the user include:

Communications – Processes often need to exchange information, on the

same computer or

between computers over a network

Further, Communications may be via

– shared memory or through

– message passing (packets moved by the OS)

Discussed ahead.

Error detection – OS needs to be constantly aware of possible errors

Hardware: May occur in CPU, I/O devices in user program, and memory hardware or

User Errors – attempting to access protected areas of the OS; common programming errors such as division by zero, subscripts out of range, timer runout, and more.


Operating System Services (Cont.)Operating System Services (Cont.) Other OS services center around ensuring efficient utilization of

resources for smooth running of the entire computing system.

Resource allocation - When multiple users or multiple jobs running concurrently, resources must be allocated to each of them

Typical resources include CPU cycles, main memory, and file storage. OS cannot permit resource monopolization by one process OS must schedule, prioritize, and otherwise control access via various

queues and other data structures.

Accounting - Keeping track of which users use how much and what kinds of computer resources

CPU time; disk storage and more are often billed to customers. Prioritized: e.g. Billed customers; students; production.


Operating System Services (Cont.)Operating System Services (Cont.) Protection and security - two critical services…

Protection involves ensuring that all access to system resources is controlled

Security of the system from outsiders

– requires user authentication,

– extends to defending external I/O devices from invalid access attempts

All of these services (quite a number that we typically take for granted!) are critically important and will be discussed in topic-specific areas such as process control memory management, and I/O control and management much later in this course.

Let’s now address the second feature we mentioned: Interfaces.


2.2 Operating System 2.2 Operating System InterfacesInterfaces

Introduction

At a very low level, operating systems provide capabilities for programs running to request a long list of services from the operating system via a mechanism we refer to as “system calls.”

At a higher level, a shell (or command interpreter) provides an interface to the user to request these services without writing a program.

Some of the handling of system calls are built into the command interpreter; others services are programs in files that may be invoked directly from a terminal when in interactive mode.

The command interpreter often realizes sequences of system calls to handled involved requests for services.


Operating System Operating System InterfacesInterfaces

Three primary mechanisms for interfacing with the OS:

1. Command-line interface (CLI)

allows user to interface directly via specific commands.

2. Graphical User Interface (GUI)

provides the user an interface with icons, etc. that represent programs, and

3. Batch interface –

very important interface deserving discussion too!

Let’s look at these…


2.2.1 CLI Interface2.2.1 CLI Interface

Sometimes the CLI is implemented in the kernel

Other times, the CLI is implemented as a special program as for Unix, Windows XP (shells).

Here. CLI acts like an interface to the kernel.

In UNIX environment are several command interpreters.

Here, the program (a shell) is running when a job is initiated or when user first logs on - for interactive systems

These various command interpreters are called shells.

Present roughly the same capabilities; ($, % prompts…)

Normally a matter of taste.

Korn shell, Bourne shell, C shell, Bash, and others.


CLI Interface (more)CLI Interface (more)

Main purpose of the command interpreter is to execute the desired command entered by the user.

Primarily accepts a command from user and executes it.

Two general ways issued commands can be implemented: 1. Sometimes the executable code exists as part of command interpreter.

A command thus requires a branch to a specific area in the command interpreter where the desired code (e.g., create, delete, list, …) is found

– Of course, this makes the command interpreter larger.

2, Commands, such as cp file1 file2,.. implemented by a systems program.

Here the command interpreter then fetches a file to be loaded and executed.

Here, the file name would be cp or mv, ls, pwd, or whatever.

Here, the Command Interpreter can thus be small – but of course, file to be executed must be fetched…

Here, the command interpreter – easily modifiable to accommodate additional commands, since the executable code does not reside in the CLI itself.


2.2.2 GUI Interface2.2.2 GUI Interface

User-friendly desktop metaphor interface Usually mouse, keyboard, and monitor

Icons represent files, programs, actions, etc

Various mouse over objects in the interface cause various actions (provide information, options, execute function, open directory (known as a folder)

Common knowledge:

Unix has dominated the CLI interface but there are GUI interfaces available, such as Common Desktop Environment (CDE) and X-Windows. (Most of my colleagues use X-Windows.)

There are also some other open source GUIs available too.

In general, Unix / Linux users normally prefer the CLI;

Most Windows GUI users almost never use MS-DOS shell interface.


3. System Calls3. System Calls Now - into the lower level services provided by the operating system.

Usually written in C or C++; sometimes assembler.

Mostly initiated by programs via a high-level Application Program Interface (API) rather than direct system call.

The application program issues a statement resulting in a system call, such as a Read or Write (printf, scanf, System.out.println()...

These do NOT directly result in an immediate system call;

Let’s first consider (from your book) the number and nature of system calls to read data from one file and copy the data to another.

A rather simple request…

This is a rather common activity we are all familiar with. (But note the number of system calls needed.)


Sample Set of System CallsSample Set of System Calls To copy a file…. We need two names – the input and output file names.

One way to get file names is via interactive program request.

If so, this will require a series of system calls

Prompt for the file name

Read from keyboard

In a mouse-based system, we likely have a menu of file names displayed in a window, and can select. This approach requires a number I/O system calls. In a CLI, there are a few text commands issued…

Once file names have been gotten, the program must

open the input file and then

open an output file that is to receive the data.

These actions require two system calls.

If there are problems / errors (file not found, etc.)

messages should be sent back to the originator (more system calls) and

the initial action is terminated abnormally (another system call).


Sample Set of System Calls (continued)Sample Set of System Calls (continued) ‘Assuming’ the input file is accessible, an output file must be created. Potential problems:

What if file with same name is present (system call). May be given option to overwrite the existing file (system call) or

delete the existing file (system call) and create a new one (system call).

(Can also request inputs / other choices from user, if done interactively.) Then, once the files are accessible and created, we need to read records from the input file

and write them to the output file. (system calls) Each read and write returns a status (end of input file, no more room in output file,

hardware failure, successful read/write, amount of data in r/w…) Ultimately, the files must be closed (system call) and some kind of confirmation message

sent to the console or window (system calls), and finally terminate normally (final system call).

So we can see that for even the simplest operation, there may be a number of system calls!!


More on System Calls (continued)More on System Calls (continued)

As an application programmer, we never see these calls!!

We simply issue a Read or a Write or whathaveyou.

We may use some kind of API (Application Programming Interface)

So we issue statements such as System.out.println(“Hello World!”);

The String is a parameter sent to the println method in System.out which invokes appropriate lower level system calls for us as part of the API.

Same thinking for printf (“Hello World from Florida!\n”);


Example of System CallsExample of System Calls

System call sequence to copy the contents of one file to another file


API AssistanceAPI Assistance Three most common APIs are

the Win32 API for Windows (which we won’t spend time on in this course)

the POSIX API for POSIX-based systems (including virtually all versions of UNIX, Linux, and Mac OS X), and

the Java API for the Java Virtual Machine (JVM)

We will look at these last two.

Functions that constitute the API invoke the actual system calls on our behalf.

Because of this, the application programmer can now produce programs that are portable on any machine supporting the same API (just about).

These are great advantages of using high powered APIs!

System calls themselves are complicated to code and often obscure what the application programmer is really trying to accommodate. Then too, many application programmers don’t want to be bothered with writing system calls! (Don’t blame them!)

(There is, it is important to note, a very strong correlation between invoking a function in an API and the associated system call in the kernel.)


Example of Standard APIExample of Standard API

Consider the ReadFile() function in the Win32 API—a function for reading a file

A description of the parameters passed to ReadFile() HANDLE file—the file to be read LPVOID buffer—a buffer where the data will be read into and written from DWORD bytesToRead—the number of bytes to be read into the buffer LPDWORD bytesRead—the number of bytes read during the last read LPOVERLAPPED ovl—indicates if overlapped I/O is being used

Note: these are only the parameters passed to the ReadFile and are used in a variety of ways by individual system calls (not shown).

Again, most application programmers don’t want to be bothered with this!!


Let’s Discuss ‘System Calls’Let’s Discuss ‘System Calls’


System Call ImplementationSystem Call Implementation System Call Interface.

The System Call Interface is part of the run-time support system.

The System Call Interface is a set of built in functions linking function calls from the API to necessary system calls (facilitated by the compiler). (next slide)

In use: When a service is desired via the API, the system call interface invokes intended system call in OS kernel and returns status of the system call and any return values once completed.

Calling process / user need not know (does not care) what happens:

Most details of OS interface hidden from programmer by API

Parameters, etc (Strings, address of where to write data, etc…) are

passed to the system call interface from API which are in turn

passed to the appropriate system call routines.

(More ahead on parameter passing)


API – System Call – OS RelationshipAPI – System Call – OS Relationship

System calls are normally indexed in a table of addresses containing required routines.

System Call Interface contains a list of these indexes and associated routines.

Control is transferred to theselocations. Good figure here…


Standard C Library ExampleStandard C Library Example

C program invoking printf() library call, which calls write() system call

System call interface

System call itself.Note it is in kernel mode.


System Call Parameter PassingSystem Call Parameter Passing

Parameter passing and other required information can be exacting.

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 Very commonly used approach for parameter passing.

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, which is good, but a bit slower than register access.


Parameter Passing via TableParameter Passing via Table

Let’s look at types of System Calls……………………………….


2.4 Types of System Calls2.4 Types of System Calls

Can group system calls into five major categories centered mostly around their provided functionality:

Process control

We’ll spend the most time here (in this and several additional chapters in this course)

File management

Device management

Information maintenance

Communications

All of these will be discussed later in appropriate chapters.

We will address briefly here.


2.4.1 Process Control2.4.1 Process Control Programs either terminate normally or abnormally.

In either event, a system call(s) is/are invoked and appropriate actions / messages are taken.

Regardless, the operating system must transfer control back to the command interpreter who initiated the process so that the user is informed of the result of his/her request.

Let’s assume a process aborts (say, division by zero is attempted)

A dump may be taken (automatically or not) and a message produced.

A debugger may examine the dump to determine the cause of the problem; control must be returned to the interface.

Command Interpreter ‘continues’ to interpret commands.

In a GUI, a message window may appear asking the user what to do with the dump data or other action to be taken..

In a batch system, the job will normally be terminated and the command interpreter will merely continue with the next job.


Process Control – Example with MS DOSProcess Control – Example with MS DOS Many variations to consider – even at this high level. Will consider MSDOS.

MS DOS is considered a single-tasking system; Will use this to illustrate. MSDOS has a command interpreter invoked when computer is started. Because it is a single-tasking system, the command interpreter uses a

simple method to run a program and does NOT create a new process.

The command interpreter simply loads a program into memory, writes over itself (covering unneeded code) to provide as much memory as possible.

The command interpreter sets the instruction pointer to point to the first executable instruction in the code and control is then transferred to that code.

The program continues and either an error causes a trap, or the program executes a system call to terminate. Error code is saved in memory later use. Control transfers back to command interpreter, which reloads the rest

of itself from disk, and command interpreter makes the error code available to the user.


MS-DOS executionMS-DOS execution

(a) At system startup (b) running a program

Process loaded into memory covering part of command interpreter.

Critical code is not covered.


Other Types of System CallsOther Types of System Calls

These will be covered extensively in:

File Management

Device Management, and

Information Management and Communications

Will be covered in depth in later chapters…

End first part of Chapter 2End first part of Chapter 2

Documents

Chapter 2: Operating-System Structures Modified Considerably by your Instructor