1. Chapter 2, Operating System Structures

2. 2.1 Operating System Services
User interface:
Command line
Batch
Graphical user interface
Program execution
Load
Run
End successfully or not

3. File system manipulation, files, directories
I/O operations
Access to physical devices (usually protected—a system service)
File system manipulation, files, directories
Read, write
Make, delete
Find, navigate

4. Communications Error detection Inter-process communication
Same computer or different systems
Message passing
Or shared memory
Error detection
In CPU
In memory
In user program
Detect and handle gracefully, allowing continued use of the system.

5. O/S functions to promote efficiency, especially on multi-user systems
Resource allocation
Scheduling CPU cycles
memory access
I/O
file system, etc.
Accounting
How much of each resource used by each user
In what pattern
At what times
Billling and system configuration

6. Protection and security
Logins and rwx type permissions
Protecting one process from another (in memory)
Protecting from outside intrusions

7. 2.2 User Operating System Interface
Command interpreter function
Setup for a command line interface
Gives the prompt
Takes in the command and takes action
Command interpreter architecture
May be part of the kernel
May be run as a separate program
May include the code to be run as subroutines
May call separate system programs based on the command entered

8. GUI—no important new information here Choice of interface
User preference
Note power of programming in a command line interface vs. a GUI

9. 2.3 System Calls Explicit system call Embedded system call
Example: copying a file
Entered from command line or through GUI
One user system call may result in a sequence of internal system calls
Embedded system call
In ASM, C, C++, etc., it is possible to include lines of code containing system calls

10. Passing parameters in the system
Implicit system calls
The compiler translates user instructions to machine instructions
At run time, machine instructions which are protected trigger system calls
The classic example is file I/O
Passing parameters in the system
Stored in registers
Stored in memory, memory address stored in register
Pushed onto the stack

11. System calls in Java Write a method in Java declared “native”
Let the native method be a holder for C or C++ (system language) code
The C/C++ code can call system programs
Note that the Java code is now platform dependent, not portable

12. 2.4 Types of System Calls Process control End, abort Load, execute
Create, terminate
Get attributes, set attributes
Wait for time
Wait for even, signal event
Allocate and free memory

13. File management Device management Create, delete Open, close
Read, write, reposition
Get attributes, set attributes
Device management
Request, release
Logically attach or detach

14. Information management
Get time or date, set time or date
Get system data, set system data
Get process, file, or device attributes
Set process, file, or device attributes
Communications
Create, delete communication connection
Send, receive messages
Transfer status information
Attach or detach remote devices

15. 2.5 System Programs
Representative of O/S code that’s not in the kernel
Some items are interfaces to call system services
Some are distinct system programs or collections of programs

16. Six categories (overlapping with previously presented lists)
File management
Status information
File modification
Programming language support (compilers, assemblers, interpreters, debuggers)
Program loading and execution (absolute loaders, relocatable loaders, linkers, etc.)
Communications

17. 2.6 Operating System Design and Implementation
Parameter one: What kind of hardware?
Parameter two: What kind of system?
Single user
Multi-user
Distributed
Real-time, etc.

18. Parameter three: User requirements
Easy to learn, use, etc.
Fast, safe, reliable, etc.
Note that there is no obvious connection between these requirements and how you code the system in order to meet them
Parameter four: Developer requirements
Easy to design, implement, maintain, etc.

19. Mechanisms and policies Software design principle, separate the two
Policy = what to do
Mechanism = how to do it
In other words, don’t hardcode policy
Implement mechanisms that can enforce different policies depending on input parameters

20. Windows takes the opposite approach
Examples
Unix
The micro-kernel can support batch, time-sharing, real-time, or any combination
What is supported depends on values in tables loaded at start-up
Windows takes the opposite approach
Mechanism and policy are tightly coupled
The system is relatively inflexible
There is a reason for this: It enforces the same look and feel across all installations

21. Originally: assembly language Modern systems ~10% assembly language
O/S implementation
Originally: assembly language
Modern systems
~10% assembly language
Context switching
Possibly process scheduling
Possibly memory management
~90% C—all remaining system functionality

22. 2.7 Operating System Structure
Simple structure = not well structured
Simple systems that grew without a plan
Systems where immediate performance needs were paramount
Monolithic systems in general

23. MS DOS example

24. The left hand set of arrows represents a layered path through the software
The right-hand, non-layered path enabled performance, but made the system error-prone

25. Original Unix example

26. The original Unix was no better
Superficially layered
The layers contained lots of stuff
Internally the layers were undisciplined in design

27. The Layered Approach

28. Design functionality from the top down
Debug from the bottom up
Each layer has data structures, code, and interface
The implementation of the layers can change as long as the interface discipline is maintained
Somewhat object-oriented
Less general because each layer interacts with two neighbors only

29. The fundamental challenge of layered systems is breaking it into layers and getting the dependencies straight
Each upper layer can only be implemented with calls to its lower neighbor
Sorting this out in the kernel is not trivial. Which is lowest, process scheduling, memory management, or some other function?
The practical disadvantage of layering is the performance cost of going down through the layers

30. Microkernels contain the bare minimum of system code
Process management
Memory management
Message passing
All other system code written into modules
Modules run like user applications
But they are privileged to make system calls
Communication between them is managed by the kernel
The kernel remains small and fast and manageable by developers
All other system programs can be changed without affecting the kernel

31. Modular Design

32. Object-oriented design
Kernel and other modules can be dynamically loaded and linked to provide needed services
Different objects/modules can communicate with each other
Modern Unix systems take this approach

33. Mac OS X

34. BSD = Berkeley Standard Distribution (kernel)
Mach = Carnegie Mellon (micro-kernel)
Different O/S functions are handled by the two
Mac OS X is a hybrid system

35. 2.8 Virtual Machines

36. Logical conclusion of multi-user, multi-tasking
Logical conclusion of layering idea
Each user has access to a simulated hardware interface
Each user can load a different O/S, access different virtual peripherals, etc.
The challenge in implementation is keeping track of real system vs. user mode and virtual system vs. user mode
Sharing and communication between virtual machines is also important

37. Benefits of virtual machines
Users can run different O/S’s
Users are completely isolated from each other
System developers can work on O/S and other system code on one virtual machine while users run on the others
The original VM system—IBM mainframe—now configured to run Linux as well as CMS
Vmware runs on Intel systems, making it possible to load >1 O/S on a system at a time

38. 2.9 Java Java has three parts Programming language specification
Application programming interface
Virtual machine specification

39. Programming language characteristics
Object-oriented
Architecture neutral
Distributed
Multi-threaded
Secure
With automatic garbage collection

40. Programming language characteristics
Object-oriented
Architecture neutral
Distributed
Multi-threaded
Secure
With automatic garbage collection

41. Java API editions JSE = standard edition EE = enterprise edition
Desktop applications and network applets
Graphics, I/O, security, db connectivity, networking
EE = enterprise edition
Server applications with db support
ME = micro edition
Applications on phones, pagers, handheld devices…

42. The Java Virtual Machine = JVM The Java platform =
An implementation of the JVM specification for any given hardware environment
Plus the Java API
The Java platform can be implemented
On top of a host O/S
In a browser
Or the JVM can be implemented in hardware

43. In a software environment, when main() is called in an application, this causes an instance of the JVM to be created
Each separate application or applet in execution has its own JVM
The JVM consists of a loader and an interpreter. The loader loads a .class file containing Java byte code
The interpreter, or just in time compiler, translates Java code into the commands and calls necessary in a given environment
Implementations of the JVM differ across environments, but not the specification

45. Random additional comments
For development purposes a Java Development Environment would consist of a compiler plus a Java Runtime Environment (JRE)
In theory you might write an O/S with a microkernel in C/ASM and the rest in Java, using Java’s type safety mechanism for security. JX is an example
The MS .NET framework is similar to the Java approach

46. 2.10 Operating System Generation
System generation = installing and setting up an O/S on a machine
Most O/S’s can fun on multiple hardware platforms
Installation requires setting parameters:
What CPU, how many, which instruction set(s)?
How much main memory?
What attached devices, type and model, numerical designation, interrupt number
O/S parameters: scheduling algorithm, number of I/O buffers, number of processes allowed, etc.

47. Approaches to system generation fall into a range:
Set parameters in source, compile O/S, install
Select precompiled modules from libraries
Table driven—select options after O/S is up and running

48. O/S performance parameters Ease and speed of installation and set-up
Performance speed and memory size at run time
Ease of modification. Most systems probably have elements of both:
Major modifications: Change settings, recompile, reinstall
Minor modifications: Change settings from table options on the fly

49. 2.11 System Boot
Already covered while going over chapter 1