Transcript Ch-2_3431x

Chapter 2 – Introduction (Pgs 49 – 91)
CSCI 3431: OPERATING SYSTEMS
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, exit
2. File manipulation: open, read, write, close
3. Device manipulation: ioctl, read, write
4. Information maintenance: getpid, alarm
5. Communications: pipe, shmget, mmap
6. Protection: chmod, umask, chown
System Programs
 Often just wrappers around SysCalls
 GUIs are wrappers for the CLI versions
1. File management: mkdir, cp, mv, cat
2. Status information: ps, df, du
3. File modification: nano, vi, emacs
4. Programming support: awk, gcc, gdb, gprof
5. Prog. Loading & execution: ld
6. 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/S
O/S on installation media needs to be tailored
for specific hardware platform and usage
 CPU(s)
 Disk format, partitions, file systems
 Memory size, structure (NUMA)
 Devices, interrupts, addresses
 User 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
#include
#include
#include
#include
#define
#define
#define
#define
#define
#define
<stdio.h>
<stdlib.h>
<sys/stat.h>
<unistd.h>
<string.h>
DEBUG
0
SUCCESS 0
FAILURE 1
BADUSE
2
BADFILE 3
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 ()