Operating System Services

Loading and Running program?

How disks are used? Opening, storing files?

How CPU/memory/IO device is used?

How programs talk with other programs on the

same or other computers?

File System Manipulation

OS: System calls

Based on slides OS Concepts by Silberschatz, Galvin and Gagne, 2008

Additional material by Diana Palsetia

Resource Management

Communication

Who logs in ? has access? What went wrong?

CIT 595

Security, protection and error detection

How does the user interact ?

A view of OS Services

User Interface

System Call

Programming interface to the services provided by

the OS
Typically written in a high-level language
Mostly accessed by programs via a high-level
Application Program Interface (API) rather than direct
system call use
Three most common APIs are

CIT 595

Process Execution, I/O Operation

Win32 API for Windows,

POSIX API for POSIX-based systems
y
(including
(
g virtually
y all
versions of UNIX, Linux, and Mac OS X),
Java API for the Java virtual machine (JVM)

Why use APIs rather than system calls?

CIT 595

API over System Call

Are system dependent

Not be a good idea to directly use system calls

when portability cannot be neglected

S t
System
calls
ll are also
l quite
it complex
l

API over System Call

Involves the duo of TRAP and RET (or some

variations of those two)

To implement system call

The caller know nothing about how the

system call is implemented

One would need specialized knowledge of I/O

registers
O d off operations
Order
i
needed
d d to use them
h
Implement enough protection because I/O
resources are generally shared among multiple
users and/or processes

CIT 595

Managed by run-time support library (set of

functions built into libraries included with
compiler)

CIT 595

Abstraction and Portability

Call a library function written in assembly

assembly, which

Calls a TRAP function written in assembly, which

Unix System Calls for File I/O

If you want to call a C function to draw a pixel,

you

JJustt needs
d to
t obey
b API and
d understand
d t d
what OS will do as a result call
Most details of OS interface hidden from
programmer by API

There are 5 basic system calls that Unix

provides for file I/O:

Moves args from stack to regs and

1. int open(char *path, int flags , mode_t mode);

Moves args from regs to stack and

Calls an OS function written in C, which

Returns
R
t
tto the
th TRAP and
d
Returns to the library function and
Returns to you

2. int close(int fd);

3. ssize_t read(int fd, void *buf, int size);
4 ssize
4.
ssize_tt write(int fd
fd, void *buf
buf, int size);

Finally draws the pixel and

CIT 595

5. off_t lseek(int fd, off_t offset, int whence);

CIT 595

File Descriptor

int open(char *path, int flags , mode_t mode)

An index for an entry in a os/kernel data structure (file

descriptor table) containing the details of all open
files

User application passes the abstract key to the

os/kernel through a system call

OS will access the file on behalf of the application,

based on the key

Open makes a request to the operating system to use

a file

path argument specifies what file you would like to use

flags and
fl
d mode
d arguments
t specify
if how
h
you would
ld lik
like
to use it

The application itself cannot read or write the file descriptor

table directly

Use mode when creating file for first time

Th
Three
file
fil d
descriptors
i t
predefined:
d fi d

CIT 595

int close(int fd)

close() tells the operating system that you
are done with a file descriptor

There is a limit on how many files a program

can open

10

ssize_t read(int fd, void *buf, int size);

because it takes resources to store all information

needed to correctly handle an opened file

So, close all files you don't currently need to

save some resources

CIT 595

This is a non-negative integer

If it returns -1, then you have been denied access
You can open the same file more than once
a different fd each time. If you open the same file for writing more
than once at a time, you may get bizarre results

On success, it will return a file descriptor to you

File descriptor 0 is standard input

File descriptor 1 is standard output
File descriptor 2 is standard error

CIT 595

E.g. flags: O_APPEND, O_CREAT, O_WRONLY(defined in

fcntl.h )
E.g. modes: S_IRWXU, S_IRUSR (defined in stats.h)

11

read size bytes from the file opened in file

descriptor fd, and to put those bytes into the
location pointed to by buf

Returns how many bytes were actually read

write syscall writes data and returns the

number
b b
bytes
t written
itt

CIT 595

12

Mechanics to open a file: Streams vs. File

Descriptors

off_t lseek(int fd, off_t offset, int whence)

All open files have a file pointer associated

with them

File descriptors are represented as

objects of type int

Streams are represented as

FILE * objects

Provide a primitive, low-level

p and output
p
interface to input
operations

Streams provide a higher-level

interface, layered on top of the
primitive file descriptor facilities

Interface provides only simple

functions for transferring blocks of
characters

Implemented in the C run-time

library

Can extract the file descriptor from a

stream and perform low-level
operations directly on the file
descriptor

Can initially open a connection as a

file descriptor and then make a
stream associated with that file
descriptor (using fdopen())

Can move the file pointer manually

How much to move is provided by offset

The whence variable specifies how the seek is to
be done
from the beginning of the file
from the current value of the pointer
from the end of the file

Upon successful completion, returns the

resulting offset location as measured in
bytes from the beginning of the file

CIT 595

13

API is provided in <stdio.h>

Provides powerful formatted

input and output functions (printf
and scanf) as well as functions
for charactercharacter and line-oriented
line oriented
input and output

CIT 595

14

Usage of streams and file descriptor

Standard C Library Example

Can also represent a connection to a device or a pipe

or socket for communicating with another process

Unless there is some specific operation you want to perform

that can only be done on a file descriptor

Portability of your programs to systems other than

GNU systems

15

Operations that are specific to a particular kind of device use a file descriptor

Use streams rather than file descriptors

CIT 595

CIT 595

Be aware that file descriptors are not as portable as streams

You can expect any system running ISO C to support
streams
But non-GNU systems may not support file descriptors at all,
or may only implement a subset of the GNU functions that
operate on file descriptors
16

perror

How do I know what .h files to include ?

Usually when an error occurs in a system or

library call, a special return value comes
back, and a global variable "errno" is set to
say what the error is
For example, suppose you try to open a file
that does not exist:

Man pages are you best friend

man s# functionname
2: System calls
3: Library calls

Search functions but dont know there name:

fd = open("in1", O_RDONLY);
if (fd < 0) {
perror(open syscall failed because");
exit(1);
}
CIT 595

Keyword search:
man -k regexp
Examples:
man -k memory
man -k locate.*string
Unix Specification:
http://www.opengroup.org/onlinepubs/009695399/

17

CIT 595

18