roadmap for section b
play

Roadmap for Section B A Brief History of Windows and Linux - PDF document

Unit OS B: Comparing the Linux and Windows Kernels Windows Operating System Internals - by David A. Solomon and Mark E. Russinovich with Andreas Polze Roadmap for Section B A Brief History of Windows and Linux Comparing the Windows and Linux


  1. Unit OS B: Comparing the Linux and Windows Kernels Windows Operating System Internals - by David A. Solomon and Mark E. Russinovich with Andreas Polze Roadmap for Section B A Brief History of Windows and Linux Comparing the Windows and Linux kernel architectures Linux: becoming more like Windows Benchmarks and other lies What does the future hold? 3 1

  2. Scope We’re going to look at the technology of the kernels We’re not going to look at: Cost Support Applications Management Use as a desktop system 4 The History of Linux The real history of Linux starts in 1969, when Ken Thompson developed the first version of UNIX at Bell Labs After Dennis Ritchie, designer of the C programming language, joined the project it debuted to the research community in an academic paper in 1974 Bell Labs released the first commercial version in 1976 as UNIX Version 6 (V6) UNIX spread throughout universities and in 1978 Bell Labs released UNIX Time-Sharing System, a version with portability in mind 5 2

  3. Linux History Continued Because Bell Labs distributed UNIX with source code, the early 1980’s saw three major branches grow on the UNIX tree: UNIX System III from Bell Lab’s UNIX Support Group (USG) UNIX Berkeley Source Distribution (BSD) from the University of California at Berkeley Microsoft’s XENIX The UNIX market fragmented further in the 1980’s, despite the IEEE’s POSIX standard and the X/Open Group’s Portability Guide 6 Linus and Linux In 1991 Linus Torvalds took a college computer science course that used the Minix operating system Minix is a “toy” UNIX-like OS written by Andrew Tanenbaum as a learning workbench Linus wanted to make MINIX more usable, but Tanenbaum wanted to keep it ultra-simple Linus went in his own direction and began working on Linux In October 1991 he announced Linux v0.02 In March 1994 he released Linux v1.0 7 3

  4. The History of Windows (NT) The history of Windows really begins in the mid-1970s, when Dick Hustvedt, Peter Lipman and David Cutler designed the VMS operating system for Digital’s 32-bit VAX processor Digital shipped VMS v1.0 in 1978 Cutler moved to Seattle to open DECWest and worked on the Digital Mica OS for a new CPU codenamed Prism 12 engineers went with him and the facility grew to 200 In 1988 Digital cancelled the project 8 The History of Windows Continued Bill Gates wanted a UNIX rival He hired Cutler and 20 Digital engineers in 1989 The new project was called NT OS/2 because it focused on OS/2 backward compatibility With the success of Windows 3.0’s 1990 release Gates refocused the project on Windows compatibility The project renamed to Windows NT Microsoft released Windows NT 3.1 in August 1993 9 4

  5. Windows and Linux Both Linux and Windows are based on foundations developed in the mid-1970s 1970 1980 1990 2000 UNIX public Linux v1.0 UNIX V6 UNIX born v2.0 v2.1 v2.2 v2.3 v2.4 v2.6 1970 1980 1990 2000 VMS v1.0 Windows XP Server 2003 Windows NT 3.1 NT 4.0 Windows 2000 10 Comparing the Architectures Both Linux and Windows are monolithic All core operating system services run in a shared address space in kernel-mode All core operating system services are part of a single module Linux: vmlinuz Windows: ntoskrnl.exe Windowing is handled differently: Windows has a kernel-mode Windowing subsystem Linux has a user-mode X-Windowing system 11 5

  6. Kernel Architectures Application Windows User Mode Kernel Mode System Services Process Management, Device Win32 Memory Management, Drivers Windowing I/O Management, etc. Application Hardware Dependent Code Linux X-Windows User Mode Kernel Mode System Services Process Management, Device Memory Management, Drivers I/O Management, etc. Hardware Dependent Code 12 Linux Kernel Linux is a monolithic but modular system All kernel subsystems form a single piece of code with no protection between them Modularity is supported in two ways: Compile-time options Most kernel components can be built as a dynamically loadable kernel module (DLKM) DLKMs Built separately from the main kernel Loaded into the kernel at runtime and on demand (infrequently used components take up kernel memory only when needed) Kernel modules can be upgraded incrementally Support for minimal kernels that automatically adapt to the machine and load only those kernel components that are used 13 6

  7. Windows Kernel Windows is a monolithic but modular system No protection among pieces of kernel code and drivers Support for Modularity is somewhat weak: Windows Drivers allow for dynamic extension of kernel functionality Windows XP Embedded has special tools / packaging rules that allow coarse-grained configuration of the OS Windows Drivers are dynamically loadable kernel modules Significant amount of code run as drivers (including network stacks such as TCP/IP and many services) Built independently from the kernel Can be loaded on-demand Dependencies among drivers can be specified 14 Comparing Portability Both Linux and Windows kernels are portable Mainly written in C Have been ported to a range of processor architectures Windows i486, MIPS, PowerPC, Alpha, IA-64, x86-64 Only x86-64 and IA-64 currently supported > 64MB memory required Linux Alpha, ARM, ARM26, CRIS, H8300, i386, IA-64, M68000, MIPS, PA-RISC, PowerPC, S/390, SuperH, SPARC, VAX, v850, x86-64 DLKMs allow for minimal kernels for microcontrollers > 4MB memory required 15 7

  8. Comparing Layering, APIs, Complexity Windows Kernel exports about 250 system calls (accessed via ntdll.dll) Layered Windows/POSIX subsystems Rich Windows API (17 500 functions on top of native APIs) Linux Kernel supports about 200 different system calls Layered BSD, Unix Sys V, POSIX shared system libraries Compact APIs (1742 functions in Single Unix Specification Version 3; not including X Window APIs) 16 Comparing Architectures Processes and scheduling SMP support Memory management I/O File Caching Security 17 8

  9. Process Management Windows Linux Process Process is called a Task Address space, handle Basic Address space, table, statistics and at least one thread handle table, statistics No inherent parent/child Parent/child relationship relationship Basic scheduling unit Threads Threads Basic scheduling unit Fibers - cooperative user- No threads per-se mode threads Tasks can act like Windows threads by sharing handle table, PID and address space PThreads – cooperative user-mode threads 18 Scheduling Priorities Windows 31 Two scheduling classes “Real time” (fixed) - priority 16-31 Fixed Dynamic - priority 1-15 Higher priorities are 16 favored 15 Priorities of dynamic threads get boosted on wakeups I/O Dynamic Thread priorities are never lowered 0 Windows 19 9

  10. Scheduling Priorities Windows Linux Has 3 scheduling classes: Two scheduling classes Normal – priority 100-139 “Real time” (fixed) - Fixed Round Robin – priority priority 16-31 0-99 Dynamic - priority 1-15 Fixed FIFO – priority 0-99 Higher priorities are Lower priorities are favored favored Priorities of normal threads go up (decay) as they use Priorities of dynamic CPU threads get boosted on wakeups Priorities of interactive threads go down (boost) Thread priorities are never lowered 20 Scheduling Priorities (cont) 31 0 Fixed Fixed FIFO Fixed Round-Robin 16 15 99 I/O Dynamic 100 I/O Normal CPU 140 0 Windows Linux 21 10

  11. Linux Scheduling Details Most threads use a dynamic priority policy Normal class - similar to the classic UNIX scheduler A newly created thread starts with a base priority Threads that block frequently (I/O bound) will have their priority gradually increased Threads that always exhaust their time slice (CPU bound) will have their priority gradually decreased “Nice value” sets a thread’s base priority Larger values = less priority, lower values = higher priority Valid nice values are in the range of -20 to +20 Nonprivileged users can only specify positive nice value Dynamic priority policy threads have static priority zero Execute only when there are no runnable real-time threads 22 Real-Time Scheduling on Linux Linux supports two static priority scheduling policies: Round-robin and FIFO (first in, first out) Selected with the sched-setscheduler( ) system call Use static priority values in the range of 1 to 99 Executed strictly in order of decreasing static priority FIFO policy lets a thread run to completion Thread needs to indicate completion by calling the sched-yield( ) Round-robin lets threads run for up to one time slice Then switches to the next thread with the same static priority RT threads can easily starve lower-prio threads from executing Root privileges or the CAP-SYS-NICE capability are required for the selection of a real-time scheduling policy Long running system calls can cause priority-inversion Same as in Windows; but cmp. rtLinux 23 11

Recommend


More recommend