Chapter 2: Operating-System Structures

1. Chapter 2: Operating-System Structures Modified from the text book

2. Chapter 2: Operating-System Structures • Operating System Services & User OS Interface • System Calls • System Programs (System utilities) • Operating System Design and Implementation • Virtual Machines

3. Operating System Services • One set of operating-system services provides functions that are helpful to the user: • User interface - Almost all operating systems have a user interface (UI). • Varies between Command-Line (CLI), Graphics User Interface (GUI), Batch • Program execution - The system must be able to load a program into memory and to run that program, end execution, either normally or abnormally (indicating error). • I/O operations - A running program may require I/O, which may involve a file or an I/O device. • File-system manipulation - The file system is of particular interest. Obviously, programs need to read and write files and directories, create and delete them, search them, list file Information, permission management.

4. A View of Operating System Services

5. Linux Layers

6. Transition from User to Kernel Mode

7. UI: Shell Command Interpreter

8. GUI

9. API – System Call – OS Relationship

10. Standard C Library Example • C program invoking printf() library call, which calls write() system call

11. System Calls • 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?

12. System Calls • 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? Portability. Simplicity.

13. Types of System Calls • Process control • File management • Device management • Information maintenance • Communications • Protection

14. Examples of Windows and Unix System Calls

15. Unix I/O Calls • fileHandle = open(pathName, flags) • A file handle is a small integer, valid only within a single process, to operate on the device or file • Pathname: a name in the file system. In unix, devices are put under /dev. E.g. /dev/ttya is the first serial port, /dev/sda the first SCSI drive • Flags: read only, read/write, append etc… • Mode may be added as the third argument for file permission • errorCode = close(fileHandle) • Kernel will free the data structures associated with the device

16. Unix I/O Calls • byteCount = read(fileHandle, buf, count) • Read at most count bytes from the device and put them in the byte buffer buf. Bytes placed from 0th byte. • Kernel can give the process fewer bytes, user process must check the byteCount to see how many were actually returned. • A negative byteCount signals an error (value is the error type) • byteCount = write(fileHandle, buf, count) • Write at most count bytes from the buffer buf • Actual number written returned in byteCount • A negative byteCount signals an error

17. System Programs/Utilities • System programs/utitilies provide a convenient environment for program development and execution. The can be divided into: • File manipulation • Status information • File modification • Programming language support • Program loading and execution • Communications • Application programs • Most users’ view of the operation system is defined by system programs, not the actual system calls

18. Linux Utility Programs (1) • Categories of utility programs: • File and directory manipulation commands. • Filters. • Program development tools, such as editors and compilers. • Text processing. • System administration. • Miscellaneous.

19. Linux Utility Programs (2)

20. Operating System Design and Implementation • Design and Implementation of OS: some approaches have proven successful • Start by defining goals and specifications • Affected by choice of hardware, type of system • User goals – convenient to use, easy to learn, reliable, safe, and fast • System goals – easy to design, implement, and maintain, as well as flexible, reliable, error-free, and efficient • Important principle: separate policy and mechanism. Policy: What will be doneMechanism: How to do it • Why?

21. Operating System Design and Implementation • Design and Implementation of OS: some approaches have proven successful • Start by defining goals and specifications • Affected by choice of hardware, type of system • User goals – convenient to use, easy to learn, reliable, safe, and fast • System goals – easy to design, implement, and maintain, as well as flexible, reliable, error-free, and efficient • Important principle: separate policy and mechanism. Policy: What will be doneMechanism: How to do it • Why? allows maximum flexibility

22. OS Design Principles • Separate policy (what to do) and mechanism (how to do) • Layered structure • Module • Monolithic kernel vs. Microkernel

23. 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

24. MS-DOS: Simple Layer Structure • 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

25. Traditional UNIX System Structure

26. Modules • Most modern operating systems implement 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

27. Solaris Modular Approach

28. Monolithic Kernel vs. Microkernel

29. Microkernel System Structure • Moves as much from the kernel into “user” space • Communication takes place between user modules using message passing • 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 • Detriments: • Performance overhead of user space to kernel space communication

30. Mac OS X Structure

31. Virtual Machines • A virtual machinetakes the layered approach to its logical conclusion. It treats hardware and the operating system kernel as though they were all hardware. • A virtual machine provides an interface identical to the underlying bare hardware. • The operating system hostcreates the illusion that a process has its own processor and (virtual memory). • Each guest provided with a (virtual) copy of underlying computer.

32. Virtual Machines (Cont.) (a) Nonvirtual machine (b) virtual machine

33. VMware Architecture

34. The Java Virtual Machine

35. Android