CSCI 3431: OPERATING SYSTEMS

Chapter 2 – Introduction (Pgs 49 – 91)

System Services - User

User interface: usually CLI or GUI Program execution: start, stop, suspend,

resume I/O operations: to/from files or devices File-system operations: directories, files,

perms, links etc. Communications – interprocess and

intermachine Error detection (and

prevention/correction)

System Services - Admin

Resource allocation: balancing, priorities

Accounting: monitoring, reporting, tuning

Protection and Security: access (perms & passwords), identification (userids), encryption, monitoring

Interfaces

Command Interpreter – text interface cmd.exe in Windows bash, sh, bsh, ksh etc. in unix, os-x JCL on some mainframes Graphical for most users – won’t cover much Hardware-based for some embedded systems

(e.g., cell phone, cash register, airbus) Communication-based for some devices (e.g.,

modems, spacecraft) Not necessarily just one interface on a

system

System Calls

Low-level tasks done by the O/S and which can be requested by programmers

Usually written in C, C++, and occassionally assembly language

In Unix, they look just like library functions#include <fcntl.h>

result = open(“/usr/tami/file1.c”, O_RDONLY);

System programmers are intimately familiar with the system calls on their system

Future programming exercises will heavily focus on these!!!

SysCall Categories

1. Process control: fork, wait, exit2. File manipulation: open, read, write,

close3. Device manipulation: ioctl, read,

write4. Information maintenance: getpid,

alarm5. Communications: pipe, shmget,

mmap6. Protection: chmod, umask, chown

System Programs

Often just wrappers around SysCalls GUIs are wrappers for the CLI

versions1. File management: mkdir, cp, mv,

cat2. Status information: ps, df, du3. File modification: nano, vi, emacs4. Programming support: awk, gcc,

gdb, gprof5. Prog. Loading & execution: ld6. Communications: ssh, talk

Operating System Design

User goals: What balance of the factors do the users need/expect?

Roles: What tasks must it be able to fulfill? What will it be used for?

Constraints: Time, money, platform ...

Risks: What are the major risks that must be considered?

No different to any other Soft. Eng. task

Levels of Concern

Policy – How the O/S will be used. May vary with deployment. Flexibility is often very important here, e.g., parameter to control the length of a time slice

Mechanism – How the O/S will fulfill its goals, e.g., timer to measure a time slice

Implementation – How the programmer will implement the mechanism, e.g., link timer to clock interrupts vs. busy waiting

Structures

Simple or Monolithic – O/S is one huge program

Layered – may require h/w support (e.g., protected/privileged modes), good idea, but complicated

Microkernel – minimise O/S (mostly communication, process, memory mgmt), put everything else into support service programs

Modular System

Basic Microkernel-like core Modules loaded at boot/run-time for

other tasks Modules can communicate directly

(saves message passing) Modules have clean interfaces (gets

many advantages of layers) Only needed modules are loaded

(saves space)

Virtual Machines

Stick a layer between the O/S and the hardware (like a hardware simulator)

Run multiple O/S on this layer First seen in IBM VM/CMS O/S Layer does not have to simulate the

hardware its sitting on – it can simulate some different platform (e.g., to support development)

Best example is VMware SGG include JVM – Why is this kind of silly?

Debugging an O/S

Really, really, hard! Often done with hardware simulators Core dump – memory contents when failure

occurred, but, its the O/S that does this! Crash = O/S kernel failure Crash dumps often use a special disk partition

that can be corrupted and has no file system O/S often provide “hooks” that other tools can

connect to in order to obtain status info Windows lets you monitor the O/S via a USB

connection from another computer

SysGen – Installing an O/SO/S on installation media needs to be

tailored for specific hardware platform and usage

CPU(s)Disk format, partitions, file systemsMemory size, structure (NUMA)Devices, interrupts, addressesUser choice of options (e.g., GUI)

To Do:

Finish reading Chapter 2 if you haven`t (pgs 49-91; this lecture): All material is testable

Read Chapter 3 (pgs 101-141; next weeks lectures)

Ensure you can write and compile simple C programs with system calls.

A System Call Example/* Lab 2 Solution, by Tami Meredith, 2011 */

#include <stdio.h>

#include <stdlib.h>

#include <sys/stat.h>

#include <unistd.h>

#include <string.h>

#define DEBUG 0

#define SUCCESS 0

#define FAILURE 1

#define BADUSE 2

#define BADFILE 3

#define BADPERMS 4

char *appname;

void error (char *msg, int code) {

fprintf(stderr,\

"%s: Error: %s\nAborting\n", appname, msg);

exit(code);

} // end error ()

void usage (int code) {

fprintf(stderr,\

"Usage: %s <file> <perms>\n", appname);

exit(code);

} // end usage ()

int main (int argc, char** argv) {

char *file;

int mode;

struct stat sbuf;

appname = argv[0];

if (argc != 3) { usage(BADUSE); }

file = argv[1];

if (sscanf(argv[2], "%o", &mode) != 1) {

error ("Invalid permissions used", BADPERMS);

}

if (stat(file, &sbuf) == -1) {

error("File not found", BADFILE);

}

if (chmod(file, mode) == -1) {

error("Failed to change permissions", FAILURE);

}

return(SUCCESS);

} // end main ()