/ Operating System :

- OS Definition :

Layer of software that :

- Acts as Interface between Application Programs and Hardware

=> Programs must go through OS to access/manipulate Hardware

- Controls the execution of Application Programs

- Manages the usage of/access to Hardware

OS =
Kernel + OS Services (a.k.a OS programs, OS utilities, System Programs)

Kernel :
* Core of the OS
* Static image loaded at the start of booting
* Most important part of the OS
* Responsible for the abstraction of Hardware
=> Provides Hardware lowest-level abstraction layer
=> Programs that need to use hardware components need only
to communicate with the Kernel using System Calls
rather than communicate with Hardware Components
directly and having to dwelve into the technical
details of each component
* Responsible for mediating the communication between programs
and hardware components
* Responsible for managing resources + the execution of programs
* 2 types :
Monolithic Kernel
MicroKernel

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 inside the Kernel VFS
* Implemented 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 : 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

(App : Write ‘Block Size’ bytes to Block Device File Name

→ Chunk loaded into Kernel Buffer
→ I/O Scheduler
→ Chunk then sent to appropriate Device)

- 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
I/ UNIX Architecture :

** Bourne Shell (sh) and Korn Shell (ksh) are associated with AT&T UNIX
** C Shell (csh) associated with Berkley UNIX
** Bash Shell (bash) associated with Linux