System Calls

• Programming interface to the services provided by the

OS
• Typically written in a high-level language (C or C++)
• Mostly accessed by programs via a high-level
Application Programming Interface (API) rather
than direct system call use
• Three most common APIs are Win32 API for
Windows, POSIX API for POSIX-based systems
(including virtually all versions of UNIX, Linux, and
Mac OS X), and Java API for the Java virtual machine
(JVM)

2.1
 Example of System Calls
• System call sequence to copy the contents of one file to
another file

2.2
Example of Standard API

2.3
 System Call Implementation

• Typically, a number is associated with each system call

• System-call interface maintains a table indexed according to
these numbers
• The system call interface invokes the intended system call in OS
kernel and returns status of the system call and any return values
• The caller need know nothing about how the system call is
implemented
• Just needs to obey API and understand what OS will do as a
result call
• Most details of OS interface hidden from programmer by API
• Managed by run-time support library (set of functions built
into libraries included with compiler)

2.4
API – System Call – OS Relationship

2.5
 System Call Parameter Passing

• Often, more information is required than simply identity of desired

system call
• Exact type and amount of information vary according to OS and
call
• Three general methods used to pass parameters to the OS
• Simplest: pass the parameters in registers
• In some cases, may be more parameters than registers
• Parameters stored in a block, or table, in memory, and address of
block passed as a parameter in a register
• This approach taken by Linux and Solaris
• Parameters placed, or pushed, onto the stack by the program and
popped off the stack by the operating system
• Block and stack methods do not limit the number or length of
parameters being passed
2.6
Parameter Passing via Table

2.7
 Types of System Calls
• Process control
• create process, terminate process
• end, abort
• load, execute
• get process attributes, set process attributes
• wait for time
• wait event, signal event
• allocate and free memory
• Dump memory if error
• Debugger for determining bugs, single step
execution
• Locks for managing access to shared data between
processes
2.8
 Types of System Calls (Cont.)

•File management
•create file, delete file
•open, close file
•read, write, reposition
•get and set file attributes
•Device management
•request device, release device
•read, write, reposition
•get device attributes, set device attributes
•logically attach or detach devices
2.9
 Types of System Calls (Cont.)
• Information maintenance
• get time or date, set time or date
• get system data, set system data
• get and set process, file, or device attributes
• Communications
• create, delete communication connection
• send, receive messages if message passing model to
host name or process name
• From client to server
• Shared-memory model create and gain access to
memory regions
• transfer status information
• attach and detach remote devices
2.10
 Types of System Calls (Cont.)

•Protection
•Control access to resources
•Get and set permissions
•Allow and deny user access

2.11
Examples of Windows and Unix System Calls

2.12
 Standard C Library Example
• C program invoking printf() library call, which
calls write() system call

2.13
 Example: Arduino

• Single-tasking
• No operating system
• Programs (sketch) loaded
via USB into flash memory
• Single memory space
• Boot loader loads program
• Program exit -> shell
reloaded

At system startup running a program

2.14
 Example: FreeBSD (Berkeley Software Distribution)
• Unix variant
• Multitasking
• User login -> invoke user’s choice of
shell
• Shell executes fork() system call to
create process
• Executes exec() to load program
into process
• Shell waits for process to
terminate or continues with user
commands
• Process exits with:
• code = 0 – no error
• code > 0 – error code 2.15
 System Services
• System programs provide a convenient environment for
program development and execution. They can be divided
into:
• File manipulation
• Status information sometimes stored in a file
• Programming language support
• Program loading and execution
• Communications
• Background services
• Application programs
• Most users’ view of the operating system is defined by
system programs, not the actual system calls
2.16
 System Services (Cont.)
• Provide a convenient environment for program development and
execution
• Some of them are simply user interfaces to system calls; others are
considerably more complex
• File management - Create, delete, copy, rename, print, dump, list, and
generally manipulate files and directories
• Status information
• Some ask the system for info - date, time, amount of available
memory, disk space, number of users
• Others provide detailed performance, logging, and debugging
information
• Typically, these programs format and print the output to the terminal
or other output devices
• Some systems implement a registry - used to store and retrieve
configuration information

2.17
 System Services (Cont.)
• File modification
• Text editors to create and modify files
• Special commands to search contents of files or perform
transformations of the text
• Programming-language support - Compilers, assemblers,
debuggers and interpreters sometimes provided
• Program loading and execution- Absolute loaders, relocatable
loaders, linkage editors, and overlay-loaders, debugging systems
for higher-level and machine language
• Communications - Provide the mechanism for creating virtual
connections among processes, users, and computer systems
• Allow users to send messages to one another’s screens,
browse web pages, send electronic-mail messages, log in
remotely, transfer files from one machine to another

2.18
 System Services (Cont.)
• Background Services
• Launch at boot time
• Some for system startup, then terminate
• Some from system boot to shutdown
• Provide facilities like disk checking, process scheduling, error
logging, printing
• Run in user context not kernel context
• Known as services, subsystems, daemons

• Application programs
• Don’t pertain to system
• Run by users
• Not typically considered part of OS
• Launched by command line, mouse click, finger poke
2.19
 Linkers and Loaders
• Source code compiled into object files designed to be loaded into any
physical memory location – relocatable object file
• Linker combines these into single binary executable file
• Also brings in libraries
• Program resides on secondary storage as binary executable
• Must be brought into memory by loader to be executed
• Relocation assigns final addresses to program parts and adjusts
code and data in program to match those addresses
• Modern general purpose systems don’t link libraries into executables
• Rather, dynamically linked libraries (in Windows, DLLs) are
loaded as needed, shared by all that use the same version of that
same library (loaded once)
• Object, executable files have standard formats, so operating system
knows how to load and start them
2.20
The Role of the Linker and Loader

2.21
Why Applications are Operating System Specific
• Apps compiled on one system usually not executable on other
operating systems
• Each operating system provides its own unique system calls
• Own file formats, etc.
• Apps can be multi-operating system
• Written in interpreted language like Python, Ruby, and
interpreter available on multiple operating systems
• App written in language that includes a VM containing the
running app (like Java)
• Use standard language (like C), compile separately on each
operating system to run on each
• Application Binary Interface (ABI) is architecture equivalent of
API, defines how different components of binary code can interface
for a given operating system on a given architecture, CPU, etc.

2.22
 Design and Implementation

• Design and Implementation of OS is not “solvable”, but some

approaches have proven successful
• Internal structure of different Operating Systems can vary widely
• Start the design by defining goals and specifications
• Affected by choice of hardware, type of system
• User goals and System goals
• User goals – operating system should be convenient to use, easy
to learn, reliable, safe, and fast
• System goals – operating system should be easy to design,
implement, and maintain, as well as flexible, reliable, error-free,
and efficient
• Specifying and designing an OS is highly creative task of software
engineering

2.23
 Policy and Mechanism

•Policy: What needs to be done?

•Example: Interrupt after every 100 seconds
•Mechanism: How to do something?
•Example: timer
•Important principle: separate policy from
mechanism
•The separation of policy from mechanism is a
very important principle, it allows maximum
flexibility if policy decisions are to be changed
later.
•Example: change 100 to 200
2.24
 Implementation
• Much variation
• Early OSes in assembly language
• Then system programming languages like Algol, PL/1
• Now C, C++
• Actually usually a mix of languages
• Lowest levels in assembly
• Main body in C
• Systems programs in C, C++, scripting languages like
PERL, Python, shell scripts
• More high-level language easier to port to other hardware
• But slower
• Emulation can allow an OS to run on non-native hardware
2.25