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 ()