Transcript Linux

Linux
Overview
COMS W4118
Spring 2008
History






Linux is a modern, free operating system based on UNIX standards
First developed as a small but self-contained kernel in 1991 by Linus
Torvalds, with the major design goal of UNIX compatibility
Its history has been one of collaboration by many users from all
around the world, corresponding almost exclusively over the Internet
It has been designed to run efficiently and reliably on common PC
hardware, but also runs on a variety of other platforms
The core Linux operating system kernel is entirely original, but it can
run much existing free UNIX software, resulting in an entire UNIXcompatible operating system free from proprietary code
Many, varying Linux Distributions including the kernel, applications,
and management tools
2
Slides based on Phil Hutto, Silberschatz
Linux Lineage










Multics: 1964 Corbato MIT, GE/Honeywell, Bell Labs
UNIX: 1969 Thompson & Ritchie AT&T Bell Labs
BSD: 1978 Berkeley Software Distribution
Commercial Vendors: Sun, HP, IBM, SGI, DEC
GNU: 1984 Richard Stallman, FSF
POSIX: 1986 IEEE Portable Operating System unIX
Minix: 1987 Andy Tanenbaum
SVR4/Solaris: 1989 AT&T and Sun
Linux: 1991 Linus Torvalds Intel 386 (i386)
Open Source: GPL, LGPL, Cathedral and Bazaar
3
Slides based on Phil Hutto, Silberschatz
Linux Distributions



Standard, precompiled sets of packages, or
distributions, include the basic Linux system, system
installation and management utilities, and ready-toinstall packages of common UNIX tools
The first distributions managed these packages by
simply providing a means of unpacking all the files into
the appropriate places; modern distributions include
advanced package management
Early distributions included SLS and Slackware


Red Hat and Debian are popular distributions from
commercial and noncommercial sources, respectively
The RPM Package file format permits compatibility
among certain Linux distributions
4
Slides based on Phil Hutto, Silberschatz
Linux Licensing

The Linux kernel is distributed under the GNU
General Public License (GPL), the terms of
which are set out by the Free Software
Foundation

Anyone using Linux, or creating their own
derivative of Linux, may not make the derived
product proprietary; software released under the
GPL may not be redistributed as a binary-only
product
5
Slides based on Phil Hutto, Silberschatz
Linux Features




Linux is a “UNIX-like” operating system that “aims
at” standards compliance
Linus Torvalds does not feel constrained to
implement things that he things are “broken” (e.g.
STREAMS) even if they are part of some standard
Still most standard things are supported and Linux
includes many innovative features
Lot’s of sharing of features occurs between rival
operating systems; if BSD or Windows or Mac OS
comes up with a good idea, Linux will quickly
incorporate a similar, often improved version
6
Slides based on Phil Hutto, Silberschatz
OS Components







Kernel: core OS code loaded at boot
Daemons: background servers that provide system
services (e.g. init, inetd, ntpd, httpd…)
Libraries: libc, libdl, etc.
System software: compilers, linkers, loaders,
debuggers, virus scanners, etc.
System monitors: top, df, ps, vmstat, etc.
Utilities: backup, compression, recovery, etc.
Interfaces: windowing (GUI), shells (CLI)
7
Slides based on Phil Hutto, Silberschatz
Modules


Modules were originally developed to support the conditional inclusion
of device drivers
Early OS kernels would need to either:







1) include code for all possible devices or
2) be recompiled to add support for a new device
Modules provided a means to dynamically add pre-compiled device
code to an existing kernel binary
Modules are basically dynamically linked libraries for the kernel!
Modules could also be unloaded if the device was no longer in use (not
usually done with DLLs)
Most modern OS kernels (e.g. Solaris, BSD, Windows) support kernel
modules
Linux uses kernel modules extensively as a structuring technique and
allows file systems, network protocols, system calls, etc. to be defined
in kernel modules
8
Slides based on Phil Hutto, Silberschatz
Linux Core Kernel

CPU Management


Memory Management


Memory addressing, allocation, page frame management,
swapping
Process Management


Interrupts, exceptions, context switching, timers
Descriptors, threads, address spaces, lifecycle,
synchronization, signals, inter-process communication
Device Management

Drivers, device caches and buffer, file systems, networking,
disk and packet scheduling
9
Slides based on Phil Hutto, Silberschatz
Core Kernel
Applications
System Libraries (libc)
Modules
System Call Interface
I/O Related
File Systems
Networking
Process Related
Scheduler
Memory Management
Device Drivers
IPC
Architecture-Dependent Code
Hardware
10
Slides based on Phil Hutto, Silberschatz
Linux Source Tree





Spend some time poking around in the source tree using
lxr.linux.no
You should familiarize yourself with the structure of the source
tree and get an idea about which directories contain the most
code
The latest kernel contains 5 to 7 million lines of code (depending
on how you count)
By comparison, Open Office is about 5 million lines of code and
the latest Debian release (kernel plus all included applications) is
about 200 million lines of code!
Take a look at the Wikipedia entry “Source lines of code” (SLOC)
for more fun …
11
Slides based on Phil Hutto, Silberschatz
Architecture Dependencies







Linux uses a clever technique to deal with architecture (CPU)
dependencies (cf. device dependencies)
Logically architecture dependencies comprise a hardware abstraction
layer (HAL) but effected code is spread across hundreds of files
One approach would be to use #ifdef macros but this leads to
unreadable code
Linux isolates and abstracts all architecture dependencies into small
functions or macros (e.g. disable interrupts)
Architecture-dependent versions of each function or macro reside in the
arch/* subdirectories
The kernel Makefile does all the work of linking the appropriate
architecture dependent versions without any #ifdefs
The only #ifdefs that appear in the kernel source are for optional
capabilities (like support for multiple processors or hyper-threading or
kernel modules) that can be compiled out during kernel configuration
12
Slides based on Phil Hutto, Silberschatz