130 likes | 307 Views
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
E N D
LinuxOverview 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 UNIX-compatible operating system free from proprietary code • Many, varying Linux Distributions including the kernel, applications, and management tools 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 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-to-install 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 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 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 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) 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 Slides based on Phil Hutto, Silberschatz
Linux Core Kernel • CPU Management • Interrupts, exceptions, context switching, timers • Memory Management • Memory addressing, allocation, page frame management, swapping • Process Management • Descriptors, threads, address spaces, lifecycle, synchronization, signals, inter-process communication • Device Management • Drivers, device caches and buffer, file systems, networking, disk and packet scheduling Slides based on Phil Hutto, Silberschatz
Core Kernel Applications System Libraries (libc) System Call Interface I/O Related Process Related File Systems Scheduler Modules Networking Memory Management Device Drivers IPC Architecture-Dependent Code Hardware 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 … 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 Slides based on Phil Hutto, Silberschatz