/ Operating System :

- OS/Kernel Definition :
OS = Kernel + OS Libraries + OS utilities (aka OS Programs, System Programs)
i.e. Shell, Compiler, Word Processor…

A kernel image for each architecture, ISA (i.e. x86, SPARCS…)

Layer of software that :

Acts as Interface between Application Programs and Hardware

=> Programs must go through OS to access/manipulate Hardware
=> Hardware is protected from being misused by Programs

- Controls the execution of Application Programs :

* Program Execution Function

- Manages the secure usage of/access to Hardware :

* Resource Allocation & Management

- Offers Abstractions :
(Hardware = Processor Type, MMU architecture, I/O Bus, PCI)
(For a kernel compiled for a particular architecture
i.e. x86-32, x86-64.)
(UNIX != Windows NT definition)

1/ Implemented as a Low Level Interface : (includes ISA)

- Hardware Abstraction Layer between Hardware and
Kernel-Mode Code
- A set of instructions, implemented in the Kernel-
mode Code, universal to all hardware
(Universal Kernel/OS calls to Hardware)
- Hides differences in hardware from Kernel-mode Code
- Kernel-mode code does not need to be changed to run
on systems with different hardware & same ISA
=> Makes Kernel Code portable across different
varieties of processors, with different
memory management unit architectures, a
variety of I/O bus architectures, different
disks when compiled for the ISA applicable
to those systems
i.e. x86 Linux will work for all processors x86
whatever Memory Architecture is, and will
support most Disks (if not, will need a
driver)… Hides hardware-dependant details

2/ Implemented as a High Level Interface :

- In relation with the Low Level Interface
- System Call Interface between the Kernel and
Application Programs
- Provides a clean and uniform interface of system
calls to Kernel from Programs independent of
hardware specificities, which will be
translated into Kernel to Hardware calls
- Hides the underlying complexity from Applications/
Devs
=> Programs that need to use hardware components need
only communicate with the Kernel using
System Calls (the system call is run in Kernel
Mode but in the process context) rather than
communicate with Hardware Components directly
and having to dwelve into the technical details
of each component (sector location, I/O type)
HAL : Portability of the Kernel-Mode Code through different hardware using same ISA
Kernel :
- Core of the OS
- Binary image loaded at the start of booting process and stays
resident in RAM
- Most important part of the OS

Provides :

I) Core Functionalities : (Process Related) (Low-Level Functions)

i) * Hardware Abstraction (HAL + System Call Interface)

- Provides Hardware Low-Level Abstraction Layer
 (HAL) + High-Level Abstraction Layer/ Virtual
Interface (SCI)

May rely upon Device Software Drivers that translate

the generic command into instructions specific
to that device if HAL not sufficient

ii) * Low-Level Memory Management/ Allocation (Virtual Memory)

- Address Space Management : Allocation of Adress
Spaces to Processes, Mapping each virtual page
to a physical page frame

iii) * Low-Level Process Management (Process Scheduling)

- Process Creation and Termination
- Process Scheduling and Dispatching
=> Determines when and how long a program
should run

iv) * Inter-Process Communication (IPC)

- Process synchronization and intercommunication

v) * Low-Level Interrupt Handling

v) * Protection + Security

May provide :

II) OS services : (I/O Related) (High-Level Functions)

i) * High-Level Memory Management

- Swapping/Paging
- Page and Segment management

iii) * High-Level Process Management

- Process Switching
- Thread Management
- Management of Process Control Blocks (PCBs)

i) * File System Management (Virtual File System)

ii) * I/O Management (I/O Devices Drivers)

iii) * Network Management (Network Drivers, Network Stack)

(Network is part of I/Os)

Kernel Common components / subsystems :

Implement the Kernel Core Functions + OS Services

- Hardware Abstraction (HAL + System Call Interface)

- Low-Level Main-Memory Management Subsystem
(Address Space Management, MMUnit)
- Low-Level Process Management Subsystem (Process Scheduler)
- Low-Level I/O Management Subsystem ()
- IPC Subsystem (Synchronization)
- Low-Level Interrupt Handling
- Protection

- High-Level Main-Memory Management (=> Swapping, Paging)

- High-Level Process Management (HL Scheduling, Threading...)
- File Management Subsystem (=> Virtual File system)
- I/O Management Subsystem (=> Device Management)
- Networking Subsystem
- Command-Interpreter Subsystem
* Kernel architectures :

Monolithic Kernel :

- Kernel Code implements both Core Functions + OS Services

(ALL SUBSYSTEMS) in one single binary running
entirely in Kernel Space, in Kernel Mode
=> Kernel-Mode Code is huge
=> Cannot start/stop a subsystem on-demand without
rewriting all the Kernel-Code and rebuilding it

- Kernel defines a Complete and Complex Hardware

Abstraction
=> HAL covers a wide range of hardware for maximum
portability in same ISA
=> System Call Interface provides a complete set of
functions that cover all OS functions
(core + services)

- Kernel Code not fractionned into different parts, each

for a specific service

- All the “subsystems” implementations share the same

Address Space, as a part of 1 single program

- All subsystems can communicate directly to one another

=> + Highly efficient & fast if implementation
complete & trustworthy
=> Overhead of subsystems’ interaction within Kernel
is very low

- All subsystems share the same Address Space (as 1 binary)

 => Modifying 1 procedure in 1 subsystem can introduce
bugs and errors in seemingly unrelated parts of
the system
=> - Error / Bug in one subsystem => whole Kernel
can halt/fail

MicroKernel :
- Kernel Code implements the minimum needed : Core
functions which are the only running in Kernel Space
=> Kernel-Mode Code is small

- OS services : implemented in User Space as Servers

=> OS services in User Space separated from the
Kernel and from each other, dealt with as
‘Programs’
=> Can be started and stopped as needed, without
interfering with the Kernel
=> Error/Bug in 1 service => Said service stops,
leaving Kernel + other unrelated services
running normally
=> More stable than Monolithic
=> Overhead of invoking servers may be high
(request goes through multiple intermediate servers)

- Kernel defines a Simple and Minimalist Hardware

Abstraction
=> HAL covers a small range of hardware
(relies more on Drivers)
=> System Call Interface provides a minimal set of
functions that cover minimal OS functions
(only core functionalities)

- Kernel is just an intermediate between ‘Servers’ :

=> Delivers messages
- Servers communicate by message passing.
- Kernel’s job is to handle the message passing, interrupt
handling, low-level process management, and possibly
the I/O
Modular Kernel

- All Subsystems are implemented as Separate Modules

- Kernel Code is fractionned into different
parts/modules, each for a subsystem
- 1 Subsystem may consist of multiple Internal
Modules, the Subsystem being a Module in itself
- The idea is to regroup related code into the same
module
- Each module communicates to others over an ‘Interface’
- Each module is loadable when needed within the Kernel
under Kernel Mode at run-time

Monolithic Modular Kernel : i.e. Linux

- All subsystems are implemented as Modules

- All the modules can be loaded into the Kernel (in Kernel
Mode) and unloaded from it as needed at run-time
dynamically
- By default, the OS comes with Core + Services Subsystems
all loaded
- Still All the Modules are tied together in the same
binary image
(unloading one might have an impact on others)
- Any Kernel Module can communicate directly to any
other Kernel Module

=> Altering the binary image of the Kernel by loading/

unloading a module at runtime FASTER THAN
rebuilding the binary image of Kernel
with/without the module
=> Loading module dynamically keeps the amount of
Kernel code that runs in Kernel Mode minimal

I.E. Unload networking module/subsystem if not needed

=> Monolithic Modular Kernel = Inter-Related Modules

** All, by default, running in Kernel Space / Mode
** Dynamically loadable/unloadable following
requirement to extend / limit services
provided by the Kernel
 ExoKernel, NanoKernel
Hybrid Kernel (Windows NT)

Layered Kernel

OS Services :
* Services considered part of the OS
i.e. windowing system, command shell...,
programming interface to the kernel
(compiler tool and library)

Device / Special Files : interface for a Device Driver which makes the Physical
Device appear in a File System as if it were an ordinary
Regular File = Sequence of bytes

Device File System mounted at /dev either :

* Implemented entirely inside the Kernel VFS

* Implemented entirely or largely in User Space as User DFS
* Implemented as a separate Kernel FS

Device File mounted inside the DFS :

i.e. /dev/cdrom, /dev/disk1

Devices Classifications :

- Byte-Based Hardware Device, Block-Based Hardware Device

- Character Devices , Block Devices, Network Devices

Device for a Byte-Based piece of Hardware :

- Requires that User Space Programs read/write data 1 byte at a time
- Serial Printers, Keyboards, Mouses...

Device for a Block-Based piece of Hardware :

- Requires that User Space Programs read/write aligned fixed-size
blocks of data (Block-Size defined by the Hardware)
- Hard Disks, CDs...

* Character Device :
= Raw Device
Device to which Data can be written and from which Data can be
read directly, without the use of any intermediate buffers
in the Kernel between the User Space Program and the Raw
Device
 => No preprocessing by the Kernel for the read/write request by
the User Space Program
(No Flow Control or Buffering/Caching)
=> Kernel (via the VFS) passes directly the request from Program
to Raw Device Driver which takes responsibility of passing
it to the Raw Device

Device may however contain internal buffers

This doesn’t mean the user process can only access

1 character/byte at a time

It all depends on the Hardware (byte-based or block-based)

=> Device may require that all reads and writes are aligned to
block boundaries (fixed block size)

= Terminals (implementing a Terminal Device)

tty

Default in FreeBSD

* Character Device Driver :

In charge of implementing this behaviour for that device
(basic I/O operations...)
Provides direct, unbuffered transfer of data directly to and from
a User Space Process
Can be written as a Module
=> Can be plugged/unplugged dynamically at run-time
depending on requirement

* Character Device File :

File System Node through which a User Space Application can
access the Character Device in an abstract transparent way,
as if it was accessing a regular file
Different from a Regular File : cannot move back and forth in the
Character File (sequencial, serial approach)

* Block Device :
Device to which Data can be written and from which data can be read
through Kernel’s caching/buffering
=> Kernel preprocessing ON : Flow Control + Caching
by the Kernel I/O Scheduler
=> Order of data lost since there is a delay between data passed
from Process to Kernel’s Buffers, and data passed from
Kernel’s Buffers to the Device
Caching will reorder the sequence of write operations, depriving
the application of the ability to know the exact disk
contents at any one instant in time

* Block Device Driver :

In charge of implementing this behaviour for that device
Provides buffered + random access to hardware devices
Allows the programmer to read or write a block of any size
(including single characters/bytes) and any alignment

Can be written as a Module

=> Can be plugged/unplugged dynamically at run-time
depending on requirement

* Block Device File :

File System Node through which a User Space Application can
access the Block Device in an abstract transparent way, as
if it was accessing a regular file
- OS Objectives :

1) Convenience :
- Make a computer more convenient/easy to use by users
=> Act as User/Computer Interface = Function 1

2) Efficiency :
- Allow computer system resources to be used in an efficient way
=> Act as Computer Resource Manager = Function 2

3) Ability to easily evolve :

- Should be constructed in a way to permit the effective development,
testing, and introduction of new system functions without
interfering with service
- Easily Upgradable/Updatable, Adaptable to technologies evolution
N.B :

Computer Systems built on levels of abstraction

Higher levels of abstraction hide details of lower levels

OS provides the following abstractions :

- Files are abstractions for I/O Devices (I.E. Disk)

* OS creates illusion that I/O devices are Files = sequences of bytes
with variable size
* No need for a programmer to deal with details of each I/O Device
(sector location, adapter bandwidth, I/O type, …) or
the structure of the data contained in the files on the storage
medium

- Virtual Memory is abstraction for Main Memory + I/O Devices

* OS creates illusion that every running Application Program is the
only one stored in/using/accessing Memory Locations
(in Main Memory + I/O Devices)
i.e. accessing keyboard, accessing memory address in RAM
* In reality, ALL the currently running Application Programs share the
use/access of the same Physical Memory
 * Each process has same uniform view of memory = Virtual Address Space

- Processes are abstractions for Processor + Main Memory + I/O Devices

* OS creates illusion that every running Application Program is the
only one which code is being executed by the Processor
* In reality, ALL the currently running Application Programs share the
use/access of the same Processor

* Hardware components : See drawn chart of a Computer System

- I/O Devices ( Mouse, Keyboard : Input

+Disk Drive : Long-term Storage of Data + Code
+Display : Output
Connected to I/O Bus through Controller/Adapter)
+
- Main Memory ( Temporary-Storage Device = Physical/Primary Memory
*Physically consists of collection of DRAM chips
*Logically organized as linear array of bytes, each
with its own unique address (array index)
starting at 0)
+
- Processor
- OS Functions :

i) OS as a User/Computer Interface :

* User = End User

- End User needs to fulfill a task

- Computer System for End User = set of Application Programs,
each serving a specific purpose and fulfilling a task
- End User need only run the Application Program and doesn’t need
to dwelve into details (Hardware, Program Execution…) which
are handled entirely by the OS

=> OS provides Program Execution Service

- OS handles the execution of the Application Program :
Multiple steps performed to execute the program :
* Instructions + data loaded into main memory
* I/O devices and files initialized
* Other resources prepared

* User = Developer

- Developer needs to program an Application Program

- Computer System for Developer = set of System Programs :
Utilities (editors, compilers, debuggers...)
+ Libraries (pre-compiled machine code which implements
frequently used functions)
They assist developers in program creation, management of
files, control and access to I/O devices...
- Developer can :
* Use Machine Instructions => Developer completely
responsible for directly controlling the computer
hardware
* Use System Programs provided by OS => Developer uses
Utilities provided by OS for program creation,
then makes calls to OS Libraries Functions in its
Application Program. While running, the Application
Program will invoke these System Programs which will
perform appropriate actions depending on OS
implementation

=> OS provides Program Development Service

- OS comes with a variety of utilities, such as editors and
debuggers, to assist programmers in creating programs
=> Application Program Development Tools

=> OS provides Access to I/O devices (using File Abstraction)

- Each I/O device requires its own peculiar set of
instructions and control signals for operation
(i.e. read, write...)
- OS provides a uniform interface that masks hardware
details for accessing + manipulating I/O devices
using simple OS File reads and writes
- OS acts as mediator, making it easier for the programmer
and for application programs to access and use
hardware without having to deal with details of each
hardware component (sector location, adapter
bandwidth, I/O type, …) or the structure of the data
contained in the files on the storage medium
=> OS provides 3 Interfaces : (ISA, ABI, API)

Binaries = application programs + libraries created

* ISA : Instruction Set Architecture (by CPU)

OS Developer perspective of the Machine

- Separates Software from Hardware

- = Set of Machine Language Instructions that
computer can use (i.e. x86-32)
- Through the Machine Language Instructions,
the ISA gives access to hardware
resources and services to
* the OS : via System ISA
* binaries : via User ISA
- = User ISA + System ISA (2 subsets)
- Application Programs and Utilities can only
access User ISA : instructions available
for binaries for computations making use
directly of hardware resources
- System ISA visible only to OS : instructions
for managing system resources / hardware

* ABI : Application Binary Interface (by OS)

Compiler Developer perspective of Machine

- Separates OS from Binaries

- Programs distributed in a binary format that
encodes program text (instructions) +
initial values of some data segments
- Defines the binary format used to encode
programs and the System Calls to be used
- Defines how the OS expects programs to use
ISA
- Defines what standard the binaries must
adhere to to run on the OS (i.e. Elf,exe)
- Defines how compilers need to compile
programs to enable them to run on the OS
- Gives binaries access to :
* Services provided by OS : through
System Call Interface (most important)
* Hardware resources and services :
directly through User ISA
- = the System Call Interface : system calls /
services
available for binaries to send to OS
+ hardware resources and services
available to binaries
through the User ISA directly
 * API : Application Programming Interface
Application Programmer perspective of Machine

- Separates Applications from Libraries

- Gives Application Programs access to :
* Services provided by Library : through High-Level-
Language (HLL) Library calls which will eventually resolve
into System Calls (most important)
* Hardware resources+services : User ISA
- Enables applications to be ported through recompilation to other
systems that support the same API (source code compatible all ABIs)
ABI :
*

API per Library

Most important Library in UNIX = C Library
=> API for C Library = POSIX-API (UNIX), Linux-Kernel-API (Linux)

Kernel definition is not unanime

OS = Kernel + Utilities
Linux is just a Kernel. It needs GNU utilities to be operational
Unix is an OS
Windows is an OS
https://en.wikipedia.org/wiki/Linux_kernel_interfaces
https://www.kernel.org/doc/htmldocs/kernel-api/ : LINUX-Kernel-API
http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/ : POSIX-API