Administrivia

Web Pages

There is a web page for the course. You can find it from my home page.

• Can find these notes there. Let me know if you can't find it.
• They will be updated as bugs are found.
• Will also have each lecture available as a separate page. I will produce the page after the lecture is given. These individual pages might not get updated.

Textbook

Text is Tanenbaum, "Modern Operating Systems".

• Available in bookstore.
• We will do part 1, starting with chapter 1.

Computer Accounts and majordomo mailing list

• You are entitled to a computer account, get it.
• Sign up for majordomo mailing list for the course. But I use the web more. If you want to send mail to me, use gottlieb@nyu.edu not the mailing list.
• You may do assignments on any system you wish, but ...
  • You are responsible for the machine. I extend deadlines if the nyu machines are down, not if yours are.
  • Please upload your assignments to the nyu systems (dates).

Homeworks and Labs

I make a distinction between homework and labs.

Labs are

• Required
• Due several lectures later (date given on assignment)
• Graded and form part of your final grade
• Penalized for lateness

• Optional
• Due beginning of Next lecture
• Not accepted late
• Mostly from the book
• Collected and returned
• Can help, but not hurt, your grade

Upper left board for assignments and announcements.

Homework: Read Chapter 1 (Introduction)

1. Introduction

Levels of abstraction (virtual machines)

• Software (and hardware, but that is not this course) is done in layers.
• The higher layers use the facilities provided by lower layers.
• Alternatively said, the upper layers are written using a more powerful and more abstract virtual machine than the lower layers.
• Using a broad brush, the layers are.
  1. Scripts (e.g. shell scripts)
  2. Applications and utilities
  3. Libraries
  4. The OS proper (the kernel)
  5. Hardware
• The kernel itself is itself normally layered, e.g.
  1. ...
  2. Filesystems
  3. Machine independent I/O
  4. Machine dependent device drivers
• The machine independent part is written assuming "virtual (i.e. idealized) hardware". Simply read a block from a "disk". But in reality one must deal with the specific disk controller.
• Often the machine independent part is more than one layer.
• The term OS is not well defined. Is it just the kernel? How about the libraries? The utilities? All these are certainly system software but not clear how much is part of the OS.

1.1: What is an operating system?

The kernel itself raises the level of abstraction and hides details. Can write to a file (a concept present in hardware) and ignore whether it is a floppy or hard disk.

The kernel is a resource manager (so users don't conflict).

How is an OS fundamentally different from a compiler (say)?

Answer: Concurrency! Per Brinch Hansen in Operating Systems Principles (Prentice Hall, 1973) writes.

The main difficulty of multiprogramming is that concurrent activities can interact in a time-dependent manner, which makes it practically impossibly to locate programming errors by systematic testing. Perhaps, more than anything else, this explains the difficulty of making operating systems reliable.

1.2 History of Operating Systems

1. Single user (no OS)
2. Batch, uniprogrammed, run to completion
3. Multiprogrammed
   • Overlap CPU and I/O
   • Multiple batches
     • IBM OS/MFT
     • IBM OS/MVT (then other names)
     • MVT is more ``efficient'' user of resources but is more difficult.
     • When we study memory management, we will see that with varying sizes questions like compaction and ``holes'' arise.
   • Time sharing
     • This is multiprogramming with rapid switching.
     • We will study scheduling when we do processor management
4. Multiple computers
   • Multiprocessors: Almost from the beginning of the computer age but now are not exotic.
   • Network OS: Make use of the multiple PCs/workstations on a LAN.
   • Distributed OS: A ``seamless'' version of above
5. Real time systems
   • Often in embedded systems
   • Soft vs hard real time. In the latter missing a deadline is a fatal error--sometimes literally.

1.3: Operating System Concepts

This will be brief. Much of the rest of the course will consist in ``filling in the details''.

1.3.1: Processes

A program in execution.

Often one distinguishes the state or context (memory image, open file) from the thread of control. Then if one has many threads running in the same task, the result is a ``multithreaded processes''.

The OS keeps information about all processes in the process table. Indeed, the OS views the process as the entry. An example of an active entity being viewed as a data structure (cf. discrete event simulations).

The set of processes forms a tree via the fork system call. The forker is the parent of the forkee.

A signal can be sent to a process to cause it to execute a predefined function (the signal handler). This can be tricky to program since the programmer does not know when in his ``main'' program the signal handler will be invoked.

1.3.2: Files

Modern systems have a hierarchy of files. A file system tree.

• In MSDOS the hierarchy is a forest not a tree. There is no file, or directory that is an ancestor if both a:\ and c:\.
• In unix the existence of symbolic links weakens the tree to a DAG

Files and directories normally have permissions

• Normally have at least rwx.
• User, group, world
• More general is access control lists
• Often files have ``attributes'' as well. For example the ext2 filesystem in linux supports a d (dump) attribute that is a hint to the dump program not to dump this file.
• When a file is opened, permissions are checked a file descriptor is returned that is used for subsequent operations

Devices (mouse, tape drive, cdrom) are often view as ``special files''. In a unix system these are normally found in the /dev directory. Some utilities that are normally applied to (ordinary) files can as well be applied to some special files. For example, when you do not have anything serious going on (i.e. as soon as you log in), type the following on unix

    cat /dev/mouse

Many systems have standard files that are automatically made available to a process upon startup. There (initial) file descriptors are fixed

• standard input: fd=0
• standard output: fd=1
• standard error: fd=2

A convenience offered by some command interpretors is a pipe

  ls | wc

1.3.3: System Calls

The way a user (i.e. program) directly interfaces with the OS. Often the component of the OS responsible for fielding system calls and dispatching them is called the envelope. Here is a picture showing some of the components and the external events for which they are the interface.

What happens when a user writes a function call like read?

1. Normal function call (in C, ada, etc.)
2. Library routine (in C)
3. Small assembler routine
   1. Move arguments to predefined place (perhaps registers)
   2. Poof (a trap instruction) and then the OS proper runs in supervisor mode
   3. Fixup result (move to correct place)

1.3.4: The shell

Assumed knowledge

Homework: 9.

1.4: OS Structure

I must note that tanenbaum is a big advocate of the so called microkernel approach in which as much as possible is moved out of the (protected) microkernel into usermode components.

In the early 90s this was popular. Digital Unix and windows NT were examples. Digital unix was based on Mach a research OS from carnegie mellon university. Lately, the growing popularity of linux has called this into question.

1.4.1: Monolithic approach

The previous picture: one big program

The system switches from user mode to kernel mode during the poof and then back when the OS does a ``return''.

But of course we can structure the system better, which brings us to.

1.4.2: Layered Systems

Some systems have more layers and are more strictly structured.

An early layered system was ``THE'' by dijkstra

1. The operator
2. User programs
3. I/O mgt
4. Operator-process communication
5. Memory and drum management

The layering was done by convention, i.e. there was no enforcement by hardware and the entire OS is linked together as one program. This is true of man modern OS systems as well (e.g., linux).

The multics system was layered in a more formal manner. The hardware provided several protection layers and the OS used them.

1.4.4: Virtual machines

Use a ``hypervisor'' (beyond supervisor) to switch between multiple Operating Systems

• Each App/CMS is a virtual 370
• CMS is a single user OS
• A system call in some App traps to the corresponding cms
• CMS believes it is running on the machine so issues I/O instructions but ...
• I/O instructions in CMS trap to VM/370