0% found this document useful (0 votes)

104 views

Linux Internals & Networking: System Programming Using Kernel Interfaces

Here are the steps for static linking: 1. Compile source files to create object files: gcc -c file1.c file2.c 2. This creates file1.o and file2.o 3. Create a static library from the object files: ar rcs libstatic.a file1.o file2.o 4. This creates a static library file called libstatic.a 5. Link the main file along with the static library: gcc main.c libstatic.a -o executable 6. This will statically link the object files in the library into the executable. So in summary, static linking involves compiling to object files,

Uploaded by

Siddharth Sidhu

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

104 views

Linux Internals & Networking: System Programming Using Kernel Interfaces

Uploaded by

Siddharth Sidhu

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 305

Linux Internals & Networking

System programming using Kernel interfaces

Team Emertxe
Contents
Linux Internals & Networking
Contents

● Introduction
● Transition to OS programmer
● System Calls
● Process
● IPC
●
Signals
● Networking
● Threads
● Synchronization
● Process Management
● Memory Management
Introduction
Introduction
Let us ponder ...

● What exactly is an Operating System (OS)?

● Why do we need OS?
● How would the OS would look like?
● Is it possible for a team of us (in the room) to create an
OS of our own?
● Is it necessary to have an OS running in a Embedded
System?
● Will the OS ever stop at all?
What is an OS
OS is an interface between application and hardware
Applications Which abstracts H/W layer from user

Hardware

Applications

Is it possible to make an embedded without OS.? Hardware

Why we need OS
● Multitasking
● Multi user
● Scheduling
● Memory management
etc ...
Linux Booting
Sequence

System Start-up BIOS / Boot Monitor

Stage 1 Boot Loader Master Boot Record

Stage 2 Boot Loader LILO, GRUB, etc

Kernel Linux

Init User Application

Control flow in OS

Interrupts System Call Exceptions

Operating System
main() Modules
Boot Initialization
Supervisor Mode

RTI

User Mode
History

1940 - 1955 ENIAC, Mechanical switches, Mainframe

computers

1955 - 1970 Concept OS, FORTRAN, IBM OS/360,

Multiprogramming, Minicomputers.
Vertical
Horizontal
1970 - 1980 UNIX, Microprocessors(intel), Personal
computers age

1980 - 1990 First computer IBM 5150, DOS, Apple

& Windows with GUI

1990 - NOW Linux, ios, Android.....

Vertical vs Horizontal
● Vertical
– Hardware & Software made by same company
– OS was integrated part of the Hardware
– Applications were propitiatory
● Horizontal
– Hardware & Software made by different company
– OS is an independent software, that can run on diversified
set of hardware
– Applications are developed by everybody (propitiatory or
open source)
Quiz
● How would the OS look like ?
a) H/W only
b) S/W only
c) S/W + H/W
● How big is OS ?
Introduction
Operating System

Humans

Program
Interface

User
Programs
Compiler Assembler Text Editor Database
OS
System and Application Programs Interface

Operating
System Operating System
HW
Interface/
Privileged
Instr
Hardware
Introduction
Kernel Architecture

● Most older operating systems are monolithic, that is, the

whole operating system is a single executable file that runs in
'kernel mode'
● This binary contains the process management, memory
management, file system and the rest (Ex: UNIX)
● The alternative is a microkernel-based system, in which most
of the OS runs as separate processes, mostly outside the
kernel
● They communicate by message passing. The kernel's job is to
handle the message passing, interrupt handling, low-level
process management, and possibly the I/O (Ex: Mach)
Introduction
Kernel Architecture

Mionolithic Kernel Micro Kernel

Based Operating System Based Operating System

Application System Call

User
Mode
VFS

IPC, File Systems

Unix Device File
Application
Server Driver Server
Scheduler, Virtual Memory
Kernel
Device
Device Drivers,
Drivers, Dispatcher...
Dispatcher... Mode
Basic IPC, Virtual Memory, Scheduling

Hardware Hardware
Introduction
Mono vs Micro

Monolithic kernel Microlithic kernel

● Kernel size increases because ● Kernel size is small because
kernel + kernel subsystems kernel subsystems run as
compiled as single binary separate binaries.
● Difficult to extension or bug ● Easily extensible and bug
fixing, fixing.
● Need to compile entire source ● Easily recover from crash
code. ● Slower due to complex message
● Bad maintainability passing between services
● Faster, run as single binary ● Process management is
● Communication between complex
services is faster. ● Communication is slow
● No crash recovery. ● Easily recoverable from
● More secure crashing
● Eg: Windows, Linux etc ● Eg: MacOS, WinNT
RTOS
● Real time means fast..?
● RTOS is an operating system that guarantees a certain
capabilities within a specified time constraint.
● RTOS must also must able to respond predictably to
unpredictable events
● We use RTOS in Aircraft, Nuclear reactor control systems
where time is crucial.
● Eg: LynxOS, OSE, RTLinux, VxWorks, Windows CE
Transition to OS programming
Course & module view

0101100
C LS

010110
01001
DS

Resorce / Service Applications

Provider LI
System Call
Interface

Kernel
EOS Abstracts HW
from users
Device Drivers

LDD Hardware
MC
Application vs OS
C Algorithms, Syntax, Logic ● Preprocessor
● Compiler
● Assembler
● Linker
● Executable file
(a.out)
OS Memory segments, process, ● Executing a program
Threads ●
Loader
Signals, IPC, Networking
Application Programming
Compilation Stages

●
Preprocessor
– Expands header files
– Substitute all macros
– Remove all comments
– Expands and all # directives
●
Compilation
– Convert to assembly level instructions
●
Assembly
– Convert to machine level instructions
– Commonly called as object files
– Create logical address
●
Linking
– Linking with libraries and other object files
Application Programming
Compilation Stages

Preprocessor .c Source Code

Expanded Source
Compiler .i Code
gcc -E file.c

Assembly Source
Assembler .s Code
gcc -S file.c

Object Code gcc -c file.c

Linker .o

Executable
Loader .out

gcc -save-temps file.c would generate all intermediate files

Application Programming
Linking - Static

● Static linking is the process of copying all library modules

used in the program into the final executable image.
● This is performed by the linker and it is done as the last
step of the compilation process.
● Its both faster and more portable, since it does not
require the presence of the library on the system where
it is run.
● Compiling two .o files also a type of static linking.
Application Programming
Linking – Static

● Create two files file1.c & file2.c with appropriate functions in them
● Compile them to create object files ("gcc -c fun1.c fun2.c"). It will
create fun1.o and fun2.o files as output
● Create a static library by using ("ar rcs fun1.o fun2.o -o libstatic.a),
with this you have completed creating your static library
● Create your main.c file by calling these two functions
● Perform a static linking (gcc main.c libstatic.a)
● This will generate your a.out, execute the program and observe the
output

Note: ar - Archive command

rcs option - r(replace), c(create), s(write an object file into archive)
Application Programming
Linking - Dynamic

● It performs the linking process when programs are

executed in the system.
● During dynamic linking the name of the shared library is
placed in the final executable file.
● Actual linking takes place at run time when both
executable file and library are placed in the memory.
● The main advantage to using dynamically linked libraries
is that the size of executable programs is reduced
● To create a dynamic library (shared object file)
Application Programming
Linking - Dynamic
●
Create two files file1.c & file2.c with appropraite functions in them
●
Create a dynamic library (shared object) ("gcc -fPIC -shared fun1.c fun2.c -o
libdynamic.so)
●
Set the environmental variable LD_LIBRARY_PATH to the directory where this
new *.so is located (ex:
LD_LIBRARY_PATH="/home/LinuxInternals/DynamicLinking")
●
Perform echo $LD_LIBRARY_PATH and ensure this variable is set properly
●
Execute export LD_LIBRARY_PATH to ensure this gets into the shell's
environmental variables ecosystem
●
Create your main.c file by calling these two functions
●
Perform a dynamic linking ("gcc main.c -L . -ldynamic)
●
This will generate your a.out, execute the program and observe the output
Note: fPIC option - Generating Position Independent Code (as it is dynamically linked)
Application Programming
Linking - Static vs Dynamic

Linking
Static Dynamic
Parameter

Executable Size

Loding Time

Memory Usage

No of Sys Calls
Executing a process
RAM Memory Layout Stack
Frame
P1
P1 Command Line
Arguments Local Variables

P2 Stack Return Address

Parameter List
Hole
P3
Heap

. .BSS

Segment
(Uninitialized)
. Data

. Initialized

Pn-1
Code Segment

Pn
Quiz
● How a user defined function works?
● How a library function works?
Storage Classes
Storage Class Scope Lifetime Memory Allocation
Within the
Till the end of the block /
auto block / Stack
function
Function
Within the block / Till the end of the block /
register Register
Function function
Within the block /
static local Till the end of the program Data Segment
Function
static global File Till the end of the program Data segment
extern Program Till the end of the program Data segment
Hands-on
● Access a static variable from outside file.
● Access a global variable from outside file.
● Combination of both static and local.
Common errors
with various memory segments

Command Line Stack Overflow / Stack Smashing

Arguments ● When ever process stack limit is over

Eg: Call a recursive function inifinite times.

Stack ● When you trying to access array beyond limits.

Hole
Eg int arr[5]; arr[100];

Memory Leak
Heap
● When you never free memory after allocating.

.BSS Eventually process heap memory will run-out

Segment

(Uninitialized)
Data

Initialized

Segmentation
Fault
● When you try to change text segment, which is a
Text Segment
read-only memory or try trying to access a memory
beyond process memory limit (like NULL pointer)
Introduction
What is Linux?

● Linux is a free and open source operating system that is

causing a revolution in the computer world
● Originally created by Linus Torvalds with the assistance of
developers called community
● This operating system in only a few short years is
beginning to dominate markets worldwide
Introduction
Why use Linux?

● Free & Open Source –GPL license, no cost

● Reliability –Build systems with 99.999% upstream
● Secure –Monolithic kernel offering high security
● Scalability –From mobile phone to stock market servers
Introduction
Linux Components

● Hardware Controllers: This subsystem is

comprised of all the possible physical devices
User in a Linux installation - CPU, memory

User Space
Application
hardware, hard disks
● Linux Kernel: The kernel abstracts and
GNU mediates access to the hardware resources,
C
Library
including the CPU. A kernel is the core of the
operating system
Linux

System Call Interface

● O/S Services: These are services that are
typically considered part of the operating
Kernel Space

system (e.g. windowing system, command

Kernel
shell)

Architecture Dependent
● User Applications: The set of applications in
Kernel Code
use on a particular Linux system (e.g. web
Hardware Platform browser)
Introduction
Linux Kernel Subsystem
●
Process Scheduler (SCHED):
– To provide control, fair access
of CPU to process, while
interacting with HW on time
●
Memory Manager (MM):
– To access system memory
securely and efficiently by
multiple processes. Supports
Virtual Memory in case of
huge memory requirement
●
Virtual File System (VFS):
– Abstracts the details of the
variety of hardware devices
by presenting a common file
interface to all devices
Introduction
Linux Kernel Subsystem
● Network Interface (NET):
– provides access to several
networking standards and a
variety of network hardware
● Inter Process
Communications (IPC):
– supports several
mechanisms for process-to-
process communication on a
single Linux system
Introduction
Virtual File System

User Processes
User space
System Calls

System Call Interface

Virtual File System – dentry & inode cache

Kernel space
FIFO
ext2 ext3 /proc sockets
Pipes

Drivers and Buffer Cache

Introduction
Virtual File System

● Presents the user with a unified interface, via the file-

related system calls.
● The VFS interacts with file-systems which interact with
the buffer cache, page-cache and block devices.
● Finally, the VFS supplies data structures such as the
dcache, inodes cache and open files tables.
– Allocate a free file descriptor.
– Try to open the file.
– On success, put the new 'struct file' in the fd table of the
process.On error, free the allocated file descriptor.
NOTE: VFS makes “Everythig is file” in Linux
Summary

Linux Device Drivers

Linux Internals

Compilation Storage Program &

Stages Classes Process
System Calls
Synchronous & Asynchronous
● Communications are two types
Synchronous Asynchronous
See in next chapters

Polling Interrupts
Interrupts
Interrupts

Hardware Software

Generates whenever a Generates by instruction

Hardware changes happens from code (eg: INT 0x80)

● Interrupt controller signals CPU that interrupt has occurred, passes

interrupt number
● Basic program state saved
● Uses interrupt number to determine which handler to start
● CPU jumps to interrupt handler
● When interrupt done, program state reloaded and program resumes
System calls
● A set of interfaces to interact with hardware devices such
as the CPU, disks, and printers.
● Advantages:
– Freeing users from studying low-level programming
– It greatly increases system security
– These interfaces make programs more portable

For a OS programmer, calling a system call is no different from a normal function call.
But the way system call is executed is way different.
System calls

User
Application

open()

User Mode
System Call Interface
Kernel Mode

● open()
● Implementation
of open() system
call
● ●

●
●
return
System Call
Calling Sequence

user task
user mode
user task executing calls system call return from system call (mode bit = 1)

kernel trap return

mode bit = 0 mode bit = 1 kernel mode
execute system call (mode bit = 0)

Logically the system call and regular interrupt follow the same flow of steps. The
source (I/O device v/s user program) is very different for both of them. Since system
call is generated by user program they are called as ‘Soft interrupts’ or ‘Traps’
System Call
vs Library Function

● A library function is an ordinary function that resides in a

library external to your program. A call to a library function is
just like any other function call
● A system call is implemented in the Linux kernel and a special
procedure is required in to transfer the control to the kernel
● Usually, each system call has a corresponding wrapper routine,
which defines the API that application programs should employ

 Understand the differences between:

• Functions
• Library functions
• System calls
 From the programming perspective they all are nothing but simple C functions
System Call
Implementation

User Mode Kernel Mode

system_call:
xyz() { … sys_xyz() {
…. …. sys_xyz()
xyz() int 0x80 … …
…. …. ret_from_sys_call:
} … }
iret

System Call Wrapper System call System call

Invocation in routine in libc handler service
application standard routine
program library
System Call
Example: gettimeofday()

● Gets the system’s wall-clock time.

● It takes a pointer to a struct timeval variable. This
structure represents a time, in seconds, split into two
fields.
– tv_sec field - integral number of seconds
– tv_usec field - additional number of usecs
System Call
Example: nanosleep()

● A high-precision version of the standard UNIX sleep call

● Instead of sleeping an integral number of seconds,
nanosleep takes as its argument a pointer to a struct
timespec object, which can express time to nanosecond
precision.
– tv_sec field - integral number of seconds
– tv_nsec field - additional number of nsecs
System Call
Example: Others

● open
● read
●
write
●
exit
● close
●
wait
● waitpid
●
getpid
● sync
●
nice
●
kill etc..
Process
Process
● Running instance of a program is called a PROCESS
● If you have two terminal windows showing on your screen,
then you are probably running the same terminal program
twice-you have two terminal processes
● Each terminal window is probably running a shell; each
running shell is another process
● When you invoke a command from a shell, the corresponding
program is executed in a new process
● The shell process resumes when that process complete
Process
vs Program

● A program is a passive entity, such as file containing a list of

instructions stored on a disk
● Process is a active entity, with a program counter specifying
the next instruction to execute and a set of associated
resources.
● A program becomes a process when an executable file is
loaded into main memory

Factor Process Program

Storage Dynamic Memory Secondary Memory
State Active Passive
Process
vs Program
Program Task

int global_1 = 0;
int global_2 = 0; local_1
stack
local_2 5
void do_somthing()
{
int local_2 = 5;
local_2 = local_2 + 1;

CPU Registers
}
heap
int main()
{ global_1
data
char *local_1 = malloc(100); global_2
.start main
do_somthing(); code
.call do_somthing
…..
}
…..
Process
More processes in memory!

P0
Stack
Free Space

P1
Heap
P2
Data
Free Space
Code
OS

Each Process will have its own Code, Data, Heap and Stack
Process
State Transition Diagram

new admitted exit terminated

interrupted

ready running

scheduler dispatch

I/O or event completion I/O or event wait

waiting
Process
State Transition Diagram

Priority
Round Robin
FCFS
Preemptive

interrupted

ready running

scheduler dispatch

I/O or event completion I/O or event wait

waiting
I/O: Keyboard
Even: Signal
Process
States

● A process goes through multiple states ever since it is

created by the OS

State Description
New The process is being created
Running Instructions are being executed
Waiting The process is waiting for some event to occur
Ready The process is waiting to be assigned to processor
Terminated The process has finished execution
Process
Descriptor

● To manage tasks:
– OS kernel must have a clear picture of what each task is
doing.
– Task's priority
– Whether it is running on the CPU or blocked on some event
– What address space has been assigned to it
– Which files it is allowed to address, and so on.
● Usually the OS maintains a structure whose fields contain
all the information related to a single task
Process
Descriptor

Pointer Process State ● Information associated with

Process ID
each process.
Program Counter ● Process state
Registers ● Program counter
Memory Limits
● CPU registers
List of Open Files
●
● CPU scheduling information
●

●
● Memory-management
●

●
information
●
● I/O status information
Process
Descriptor – State Field

● State field of the process descriptor describes the state of

process.
●
The possible states are:

State Description
TASK_RUNNING Task running or runnable
TASK_INTERRUPTIBLE process can be interrupted while sleeping

TASK_UNINTERRUPTIBLE process can't be interrupted while sleeping

TASK_STOPPED process execution stopped

TASK_ZOMBIE parent is not issuing wait()
Process
Descriptor - ID

● Each process in a Linux system is identified by its unique

process ID, sometimes referred to as PID
● Process IDs are numbers that are assigned sequentially by
Linux as new processes are created
● Every process also has a parent process except the
special init process
● Processes in a Linux system can be thought of as arranged
in a tree, with the init process at its root
● The parent process ID or PPID, is simply the process ID of
the process’s parent
Process
Schedule

P1 P2 P3 P4
Stack Stack Stack Stack
User space

Heap Heap Heap Heap

Data Data Data Data
Code Code Code Code
Kernel space

Addr PS Addr PS Addr PS Addr PS

PID PID PID PID
PC PC PC PC
REG REG REG REG
Memory Memory Memory Memory
Files Files Files Files
Process
Active Processes

● The ps command displays the processes that are running on your

system
● By default, invoking ps displays the processes controlled by the
terminal or terminal window in which ps is invoked
●
For example (Executed as “ps –aef”):

user@user:~] ps -aef
UID PID PPID C STIME TTY TIME CMD
Process
root 1 0 0 12:17 ? 00:00:01 /sbin/init
ID root 2 0 0 12:17 ? 00:00:00 [kthreadd]
root 3 2 0 12:17 ? 00:00:02 [ksoftirqd/0]
Parent
root 4 2 0 12:17 ? 00:00:00 [kworker/0:0]
Process root 5 2 0 12:17 ? 00:00:00 [kworker/0:0H]
ID root 7 2 0 12:17 ? 00:00:00 [rcu_sched]
Process
Context Switching

● Switching the CPU to another task requires saving the state of

the old task and loading the saved state for the new task
● The time wasted to switch from one task to another without
any disturbance is called context switch or scheduling jitter
● After scheduling the new process gets hold of the processor
for its execution
Context Switching

process P0 operating system process P1

Interrupt or system call

executing

save state into PCB0

●
idle
●

reload state from PCB1

idle Interrupt or system call executing

save state into PCB1

●

●
idle

reload state from PCB0

executing
Process
Creation

● Two common methods are used for creating new process

● Using system(): Relatively simple but should be used
sparingly because it is inefficient and has considerably
security risks
● Using fork() and exec(): More complex but provides
greater flexibility, speed, and security
Process
Creation - system()

● It creates a sub-process running the standard shell

● Hands the command to that shell for execution
● Because the system function uses a shell to invoke your
command, it's subject to the features and limitations of
the system shell
● The system function in the standard C library is used to
execute a command from within a program
● Much as if the command has been typed into a shell
Process
Creation - fork()

●
fork makes a child process that is an exact copy of its
parent process
●
When a program calls fork, a duplicate process, called the
child process, is created
●
The parent process continues executing the program from
the point that fork was called
●
The child process, too, executes the same program from
the same place
●
All the statements after the call to fork will be executed
twice, once, by the parent process and once by the child
process
Process
Creation - fork()

● The execution context for the child process is a copy of

parent's context at the time of the call
int child_pid;
int child_status;

int main() fork()

{
int ret;
Stack Stack
ret = fork();
switch (ret)
{
Heap ret = 0 Heap
case -1:
perror(“fork”);
exit(1); Data Data
case 0:
<code for child process> Code ret = xx Code
exit(0);
default:
<code for parent process>
wait(&child_status);
}
}
Process
fork() - The Flow

PID = 25

Data
Text
Stack
Process Status

Linux
Kernel
Process
fork() - The Flow

PID = 25
Files
Data
Text
Stack Resources

Process Status

ret = fork();
switch (ret)
{
case -1:
perror(“fork”);
exit(1);
case 0:
<code for child>
exit(0);
default:
<code for parent>
wait(&child_status); Linux
}
Kernel
Process
fork() - The Flow

PID = 25
Files
Data
Text
Stack Resources

Process Status

ret = fork();
switch (ret)
{
case -1:
perror(“fork”);
exit(1);
case 0:
<code for child>
exit(0);
default:
<code for parent>
wait(&child_status); Linux
}
Kernel
Process
fork() - The Flow