Operating Systems Overview Lecture #2 Operating Systems Overview

강의 내용 운영체제의 개요 운영체제의 발전 역사 현대 운영체제의 특징 시스템 호출 운영체제의 구조 1) 직렬 처리 시스템 2) 단순 일괄처리 시스템 3) 다중 프로그램 일괄처리 시스템 4) 시분할 시스템 현대 운영체제의 특징 시스템 호출 운영체제의 구조 Operating System

Operating System 응용 프로그램의 실행을 제어하는 프로그램 사용자와 하드웨어 사이의 인터페이스 OS는 사용자의 요구에 맞추어 응용 프로그램의 실행과 종료를 제어한다 OS는 다수의 응용 프로그램 사이에 효율적인 자원 공유를 제어한다 사용자와 하드웨어 사이의 인터페이스 응용 프로그램에 제공하는 기능에 대해 하드웨어의 상세한 제어 기능을 감추다 (Masking) 예: 하드디스크 입출력, 프린터 출력 등 OS가 하드웨어의 세부적인 제어를 수행하여야 한다 Operating System

컴퓨터 시스템의 계층적 구조 Application Programs Utilities Operating-System End User Programmer Operating- System Designer Computer Hardware Operating-System Utilities Application Programs 컴퓨터 시스템의 계층적 구조 Operating System

OS Services(1) 프로그램 개발 환경 제공 프로그램 실행 I/O 와 파일에 대한 접근 시스템 접근 editors, compilers, linkers, and debuggers 프로그램 실행 loading in memory, I/O and file initialization I/O 와 파일에 대한 접근 외부 장치에 대한 입출력 및 파일 입출력 시스템 접근 시스템 자원 및 데이터에 대한 접근 보호 시스템 자원 접근 충돌 해결 Operating System

OS Services(2) 에러 검출 에러 해결 내부 및 외부 하드웨어 에러 소프트웨어 에러 운영체제 에러 간단한 에러 리포팅 memory error device failure 소프트웨어 에러 arithmetic overflow access forbidden memory locations 운영체제 에러 에러 해결 간단한 에러 리포팅 오퍼레이션의 재시도 응용 프로그램 중단 Operating System

OS Services(3) 계정 관리 시스템 자원 사용에 대한 통계 수집 시스템 성능 모니터링 (eg: response time) 시스템 튜닝 자료 수집 과금 자료 수집 (on multiuser systems) Operating System

운영체제의 발전 OS는 하드웨어의 기능향상 및 새로운 종류의 하드웨어을 적절히 이용하여야 한다 Character vs graphic terminals paging hardware 등 OS는 새로운 서비스를 제공하여야 한다 예: internet support 등 OS의 설계 및 구현 기술에 따른 변화의 필요성 modular construction with clean interfaces object oriented methodology Operating System

운영체제의 발전 역사 직렬 처리 시스템(Serial Processing) 단순 일괄처리 시스템(Simple Batch Processing) 다중 프로그램 일괄 처리 시스템 (Multiprogrammed Batch Processing) 시분할 시스템(Time-Sharing Systems) Modern Operating Systems: 병렬 시스템(Parallel Systems) : SMP 분산 시스템(Distributed Systems) 실시간 시스템(Real-Time Systems) 내장형 시스템(Embedded Systems) Operating System

직렬 처리 시스템(Serial Processing) 가장 초창기 컴퓨터 시스템 환경 (late 1940s~mid 1950s) 프로그래머가 직접 컴퓨터 하드웨어를 제어 운영체제가 없다 주요 문제점: Scheduling: 비효율적인 job scheduling Setup time: 하나의 job을 수행하기 위한 setup time이 상당히 길다 Operating System

단순 일괄 처리 시스템 (1) 최초의 운영 체제 (mid-1950s) 동작 방식: 사용자는 카드 등으로 작성된 작업(job)을 컴퓨터 운영자에 제출한다 컴퓨터 운영자는 제출된 사용자 작업을 묶어 일괄작업(batch)을 컴퓨터에 입력한다 ‘모니터(Monitor)’ 프로그램이 일괄작업의 각 작업을 순서대로 실행한다 상주 모니터(Resident monitor)는 항상 실행되기 위해 주기억장치에 상주한다 모니터 유틸리티는 필요할 때에 주기억장치에 올라온다(loading) Operating System

단순 일괄 처리 시스템 (2) Early batch system bring cards to 1401 read cards to tape put tape on 7094 which does computing put tape on 1401 which prints output Operating System

Simple Batch System Operation Operating System

모니터(Monitor) 모니터는 입력장치(카드판독기)에서 각 작업(사용자 프로그램)을 하나씩 읽어 들여 주기억장치에 저장한다(loading) 모니터 명령어에 의해 사용자 프로그램 실행이 시작된다 사용자 프로그램은 다음 상황 까지 실행된다: end-of-program 명령어 에러 발생 하나의 사용자 프로그램이 종료되면 다시 모니터가 실행된다. Operating System

Job Control Language (JCL) (1) 모니터에게 작업 실행과 관련된 명령을 주기 위한 언어 what compiler to use what data to use 작업 포맷의 예: ----------------->> ‘$FTN’ 는 컴파일러을 불러 들여 프로그램 번역을 수행 하도록 한다 ‘$LOAD’는 번역된 객체 코드를 주기억장치에 올린다(loading) ‘$RUN’ 는 사용자 프로그램을 실행한다 $JOB $FTN ... FORTRAN program $LOAD $RUN Data $END Operating System

Job Control Language (JCL) (2) Structure of a typical FMS job – 2nd generation Operating System

Job Control Language (JCL) (3) Punch card Operating System

일괄 처리 운영체제 CPU 및 다른 컴퓨터 자원의 유휴시간이 크다 사용자 프로그램과 모니터 프로그램을 교대로 실행한다 사용자 프로그램이 입출력을 수행하는 경우에 CPU는 입출력 작업이 종료될 때까지 idle 상태에 있는다 사용자 프로그램과 모니터 프로그램을 교대로 실행한다 주기억장치 상의 여러 프로그램을 효율적인 교대 수행하기 위해서는 하드웨어 지원을 필요로 한다 Operating System

하드웨어 기능 향상(1) 메모리 보호 타이머 사용자 프로그램이 시스템 영역의 메모리에 접근할 수 없도록 메모리 보호 기능 지원 하나의 작업이 시스템을 독점하는 것을 막는다 주어진 시간이 지나면 인터럽트를 발생한다 Operating System

하드웨어 기능 향상(2) 특권 명령어 인터럽트 두개의 CPU 명령어 모드 지원 모니터에 의해서만 수행되는 명령어 사용자 모드 모니터 모드(또는 슈퍼바이저(Supervisor) 모드) 모니터에 의해서만 수행되는 명령어 사용자 프로그램이 실행하면 인터럽트 발생 인터럽트 사용자 프로그램과 모니터 사이의 제어권 전환을 융통성있게 할 수 있도록 지원 Operating System

다중 프로그램 일괄처리 시스템(1) I/O 동작의 수행속도는 연산 명령어에 비하여 상당히 느리다 주기억장치에 하나의 프로그램만 있는 경우 (uniprogramming)에는 CPU의 효율성이 떨어진다 Operating System

다중 프로그램 일괄처리 시스템(2) 만약 주기억장치에 여러 개의 프로그램이 있는 경우, 하나의 프로그램이 입출력 작업을 기다리는 동안 CPU 는 다른 프로그램을 실행할 수 있다. Multiprogramming 주기억장치 Monitor Program A Program B Program C Operating System

다중 프로그램 일괄처리 시스템(3) Operating System

단일 및 다중 프로그래밍 비교 (1) 예제: Operating System

단일 및 다중 프로그래밍 비교 (2) Operating System

단일 및 다중 프로그래밍 비교 (3) Operating System

다중 프로그래밍 요구 사항 하드웨어 지원: OS의 소프트웨어 지원: I/O 인터럽트와 (possibly) DMA 메모리 관리 메모리 보호 (for data and programs) OS의 소프트웨어 지원: 작업 스케줄링 다음에 어떤 프로그램을 실행할 것인지를 결정 자원 요구 충돌 관리 Operating System

시분할 시스템(Time Sharing Systems)(1) 다중 프로그램 일괄처리 시스템은 사용자의 대화식 작업을 지원하지 않는다 긴 작업 반환 시간(Job Turnaround Time) 사용자의 반응 시간이 느리기 때문에 일반적으로 분당 2초 정도만이 실제 처리시간으로 이용한다 최적의 경우에 분당 30명의 사용자가 시스템을 공유할 수 있다 Operating System

시분할 시스템(Time Sharing Systems)(2) 시분할 시스템은 다수의 대화식 작업을 지원하기 위하여 다중 프로그래밍 방식을 확장한 시스템이다 다수의 사용자들이 프로세서 시간을 공유하도록 한다 Time Slice : 하나의 작업이 프로세서를 점유하는 시간 짧은 반응 시간(Respone Time) 다수의 사용자가 터미널에서 동시에 시스템을 사용할 수 있다(대화식 작업 수행) 파일 시스템 등이 보호되어야 한다 Operating System

시분할 시스템(Time Sharing Systems)(3) If Time Slice = 10 msec, Pgm A Pgm B Pgm C 10 ms 20ms 30 ms 40 ms 50 ms 60ms RUN 주기억장치 Program A (30 msec) Program B (20 msec) Program C (10 msec)  Operating System

Batch Multiprogramming vs. Time Sharing Both batch processing and time sharing use multiprogramming. The key differences are listed here

Early Example: CTSS Compatible Time-Sharing System (CTSS) Developed at MIT as project MAC Time Slicing: When control was passed to a user User program and data loaded Clock generates interrupts about every 0.2 sec At each interrupt OS gained control and could assign processor to another user One of the first time-sharing operating systems to be developed was the Compatible Time-Sharing System (CTSS) developed at MIT by a group known as Project MAC The system ran on a computer with 32,000 36-bit words of main memory, with the resident monitor consuming 5000 of that. When control was to be assigned to an interactive user, the user’s program and data were loaded into the remaining 27,000 words of main memory. A program was always loaded to start at the location of the 5000th word to simplified both the monitor and memory management. A system clock generated interrupts at a rate of approximately one every 0.2 seconds. At each clock interrupt, the OS regained control and could assign the processor to another user. This technique is known as time slicing. At regular time intervals, the current user would be preempted and another user loaded in. To preserve the old user program status for later resumption, the old user programs and data were written out to disk before the new user programs and data were read in. Subsequently, the old user program code and data were restored in main memory when that program was next given a turn.

CTSS Operation To minimize disk traffic, user memory was only written out when the incoming program would overwrite it. Assume that there are four interactive users with the following memory requirements, in words: • JOB1: 15,000 • JOB2: 20,000 • JOB3: 5000 • JOB4: 10,000 Initially, the monitor loads JOB1 and transfers control to it (a). Later, the monitor decides to transfer control to JOB2. Because JOB2 requires more memory than JOB1, JOB1 must be written out first, and then JOB2 can be loaded (b). Next, JOB3 is loaded in to be run. However, because JOB3 is smaller than JOB2, a portion of JOB2 can remain in memory, reducing disk write time (c). Later, the monitor decides to transfer control back to JOB1. An additional portion of JOB2 must be written out when JOB1 is loaded back into memory (d). When JOB4 is loaded, part of JOB1 and the portion of JOB2 remaining in memory are retained (e). At this point, if either JOB1 or JOB2 is activated, only a partial load will be required. In this example, it is JOB2 that runs next. This requires that JOB4 and the remaining resident portion of JOB1 be written out and that the missing portion of JOB2 be read in (f).

시분할 시스템의 요구 사항 메모리 보호 파일시스템 보호 자원 사용 충돌 Multiple jobs in memory must be protected from each other’s data 파일시스템 보호 File system must be protected so that only authorised users can access 자원 사용 충돌 Contention for resources must be handled Printers, storage etc Time sharing and multiprogramming raise a host of new problems for the OS. If multiple jobs are in memory, then they must be protected from interfering with each other by, for example, modifying each other’s data. With multiple interactive users, the file system must be protected so that only authorized users have access to a particular file. The contention for resources, such as printers and mass storage devices, must be handled.

Modern Operating Systems의 특징(1) 최근에 운영체제에 새로운 기능요소가 지원 되고 있다 새로운 하드웨어의 발전 multiprocessor machines high-speed networks faster processors and larger memory 새로운 소프트웨어 필요성 multimedia applications Internet and Web access Client/Server applications Operating System

Modern Operating Systems의 특징(2) Microkernel Architecture Multithreading Symmetric Multiprocessing Distributed Systems Embedded Systems Object-Oriented Design Operating System

Microkernel architecture 커널에서 가장 필수적인 기능만을 지원 primitive memory management (address space) Interprocess communication (IPC) basic scheduling 다른 OS 서비스는 사용자 모드 프로그램(servers) 으로 제공 device drivers, file system, virtual memory… More flexibility, extensibility, portability… 최근 운영체제는 microkernel 구조를 기반으로 하고 있다(예: Window-NT 등) Operating System

Multithreading 하나의 프로세스는 동시에 수행 가능한 thread 들의 집합이다 직렬적으로 수행할 필요가 없는 task로 이루어지는 응용 프로그램에 가장 유용하다 서버 프로그램: 웹서버 프로그램 등 하나의 프로세스를 구성하는 thread는 동일한 데이터와 자원을 공유한다 Operating System

Symmetric Multiprocessing (SMP) 다수의 프로세서를 가진 컴퓨터 각 프로세서는 동일한 기능을 가지며 주기억장치와 I/O 장치를 공유한다(symmetric) 운영체제는 프로세스/쓰레드를 프로세서간에 스케쥴링한다(real parallelism) Incremental growth just add another CPU! Robustness a single CPU failure does not halt the system, only the performance is reduced Operating System

Example of parallel execution on SMP Operating System

Distributed Systems 고유의 프로세서와 로컬 메모리를 가진 시스템이 다수 모여 구성된 컴퓨터 시스템 Loosely-coupled multiprocessor systems Clustered Systems 분산 운영체제의 특징: 자원 공유: 분산파일시스템 등 연산속도 향상: 부하분산(load balancing) 등 신뢰성(reliability): HA(High Availability) 등 Operating System

Embedded Systems 작고, 전자 책과 메모 패드와 같은 적은 기능을 수행하는 작은 규모의 컴퓨터 PDA, 이동전화기, 가전장치 등의 장치에 내장되어 장치를 제어하는 컴퓨터 실시간 특성을 가짐 크기, 메모리 및 전원 등에서 제약 조건을 가짐 임베디드 운영체제 사례: RTOS(Real-time Operating System)- pSos etc Window-CE, Embedded Window-XP Embedded Linux Operating System

Object-Oriented Design 가장 최근에 이루어진 운영체제 기술 혁신 객체 지향 설계 원리는 핵심 기능을 가진 작은 커널을 모듈러하게 확장할 수 있도록 지원 프로그래머가 시스템의 무결성을 헤치지 않으면서 자신이 원하는 대로 운영체제를 구성할 수 있다 분산 도구 및 완전환 형태의 분산운영체제의 개발을 용이하게 한다 Operating System

시스템 호출 (1) 시스템 호출(System Calls) 사용자 프로그램과 운영체제 간의 인터페이스 표준 라이브러리 함수를 통한 호출 어셈블리어 수준에서의 직접 호출 시스템 호출 사용 예: 파일 복사 프로그램 입력 파일 이름 및 출력 파일 이름에 대한 입출력 입력 파일 개방 / 출력 파일 생성 파일 읽기 / 파일 쓰기 파일 닫기 메시지 출력 프로그램 종료 Operating System

시스템 호출 (2) 사용자 프로그램 시스템 호출 운영체제 프로그래머 관점 Operating System

시스템 호출 수행 과정 There are 11 steps in making the system call read (fd, buffer, nbytes) Operating System

시스템 호출 종류 (1) 프로세스 제어(Process Control) 프로세스 생성 및 종료 프로세스 적재 및 실행 프로세스 속성 설정 및 획득 등 Operating System

시스템 호출 종류 (2) A stripped simple shell: while (TRUE) { /* repeat forever */ type_prompt( ); /* display prompt */ read_command (command, parameters) /* input from terminal */ if (fork() != 0) { /* fork off child process */ /* Parent code */ waitpid( -1, &status, 0); /* wait for child to exit */ } else { /* Child code */ execve (command, parameters, 0); /* execute command */ } Operating System

시스템 호출 종류 (3) 파일 조작(File Management) 파일 생성 및 삭제 파일 개방 및 닫기 파일 쓰기 및 읽기 파일 속성 설정 및 획득 Operating System

시스템 호출 종류 (4) 디렉토리 조작(Directory Management) 디렉토리 생성 및 삭제 디렉토리 링크 파일시스템 Mounting Operating System

시스템 호출 종류 (5) 기타 시스템 호출 장치 조작(Device Management) 장치 요구 및 해제 판독, 기록, 재배치 장치 속성 획득 및 설정 정보 유지 보수(Information Maintenance) 시간, 일자 정보 설정 시스템 자료 설정 등 통신(Communication) 통신 연결 생성 및 제거 자료 송수신 등 Operating System

시스템 호출 종류 (6) Operating System

시스템 호출 종류 (7) Some Win32 API calls Operating System

운영체제 구조(1) 시스템 프로그램 사용자 관점의 운영체제 프로그램 개발과 실행 환경 제공 시스템 관리 기능 제공 파일 조작 기능 제공 시스템 호출에 대한 사용자 인터페이스 제공 예: 컴파일러, 윈도우 탐색기, 제어판, 프린터 등 Operating System

운영체제 구조(2) Operating System

전통 UNIX OS 구조 (1) Figure 2.15 provides a general description of the classic UNIX architecture. The underlying hardware is surrounded by the OS software. The OS is often called the system kernel, or simply the kernel, to emphasize its isolation from the user and applications. It is the UNIX kernel that we will be concerned with in our use of UNIX as an example in this book. UNIX also comes equipped with a number of user services and interfaces that are considered part of the system. These can be grouped into the shell, other interface software, and the components of the C compiler (compiler, assembler, loader). The layer outside of this consists of user applications and the user interface to the C compiler.

전통 UNIX OS 구조 (2) Operating System

A closer look at the kernel is provided in Figure 2. 16 A closer look at the kernel is provided in Figure 2.16 . User programs can invoke OS services either directly or through library programs. The system call interface is the boundary with the user and allows higher-level software to gain access to specific kernel functions. At the other end, the OS contains primitive routines that interact directly with the hardware. Between these two interfaces, the system is divided into two main parts, one concerned with process control and the other concerned with file management and I/O. The process control subsystem is responsible for memory management, the scheduling and dispatching of processes, and the synchronization and interprocess communication of processes. The file system exchanges data between memory and external devices either as a stream of characters or in blocks. To achieve this, a variety of device drivers are used. For block-oriented transfers, a disk cache approach is used: A system buffer in main memory is interposed between the user address space and the external device.

Modern UNIX Kernel Operating System

Modern UNIX Systems System V Release 4 (SVR4) Solaris 9 4.4BSD Linux Operating System

Windows Architecture Modular structure for flexibility Executes on a variety of hardware platforms Supports application written for other operating system Operating System

Operating System

Windows - OS Organization Modified microkernel architecture Not a pure microkernel Many system functions outside of the microkernel run in kernel mode Any module can be removed, upgraded, or replaced without rewriting the entire system Operating System

Windows - Kernel-Mode Components Executive Contains base operating system services Memory management Process and thread management Security I/O Interprocess communication Kernel Consists of the most used components Operating System

Windows - Kernel-Mode Components Hardware abstraction layer (HAL) Isolates the operating system from platform-specific hardware differences Device drivers Translate user I/O function calls into specific hardware device I/O requests Windowing and graphics systems Implements the graphical user interface (GUI) Operating System

Windows - Executives I/O manager Cache manager Object manager Plug and play manager Power manager Security reference monitor Virtual memory manager Process/thread manager Configuration manager Local procedure call (LPC) facility Operating System

Windows - User-Mode Processes Special system support processes Ex: logon process and the session manager Service processes Environment subsystems User applications Operating System

Windows - Client/Server Model Simplifies the Executive Possible to construct a variety of APIs Improves reliability Each service runs on a separate process with its own partition of memory Clients cannot not directly access hardware Provides a uniform means for applications to communicate via LPC Provides base for distributed computing Operating System

Windows - Threads and SMP Operating system routines can run on any available processor Different routines can execute simultaneously on different processors Multiple threads of execution within a single process may execute on different processors simultaneously Server processes may use multiple threads Share data and resources between process Operating System

Windows - Windows Objects Encapsulation Object consists of one or more data items and one or more procedures Object class or instance Create specified instances of an object Inheritance Support to some extent in the Executive Polymorphism Operating System

Operating System

Table 2.5 Windows Kernel Control Objects There are two categories of objects used by Windows for synchronizing the use of the processor: • Dispatcher objects: The subset of Executive objects which threads can wait on to control the dispatching and synchronization of thread-based system operations. These are described in Chapter 6 . • Control objects: Used by the Kernel component to manage the operation of the processor in areas not managed by normal thread scheduling. Table 2.5 lists the Kernel control objects. Windows is not a full-blown object-oriented OS. It is not implemented in an object-oriented language. Data structures that reside completely within one Executive component are not represented as objects. Nevertheless, Windows illustrates the power of object-oriented technology and represents the increasing trend toward the use of this technology in OS design. Table 2.5 Windows Kernel Control Objects

LINUX Overview Started out as a UNIX variant for the IBM PC Linus Torvalds, a Finnish student of computer science, wrote the initial version Linux was first posted on the Internet in 1991 Today it is a full-featured UNIX system that runs on several platforms Is free and the source code is available Key to success has been the availability of free software packages Highly modular and easily configured Linux started out as a UNIX variant for the IBM PC (Intel 80386) architecture. Linus Torvalds, a Finnish student of computer science, wrote the initial version. Torvalds posted an early version of Linux on the Internet in 1991. Since then, a number of people, collaborating over the Internet, have contributed to the development of Linux, all under the control of Torvalds. Because Linux is free and the source code is available, it became an early alternative to other UNIX workstations, such as those offered by Sun Microsystems and IBM. Today, Linux is a full-featured UNIX system that runs on all of these platforms and more, including Intel Pentium and Itanium, and the Motorola/IBM PowerPC. Key to the success of Linux has been the availability of free software packages under the auspices of the Free Software Foundation (FSF). FSF’s goal is stable, platform-independent software that is free, high quality, and embraced by the user community. FSF’s GNU project 3 provides tools for software developers, and the GNU Public License (GPL) is the FSF seal of approval. Torvalds used GNU tools in developing his kernel, which he then released under the GPL. Thus, the Linux distributions that you see today are the product of FSF’s GNU project, Torvald’s individual effort, and the efforts of many collaborators all over the world. In addition to its use by many individual programmers, Linux has now made significant penetration into the corporate world. This is not only because of the free software, but also because of the quality of the Linux kernel. Many talented programmers have contributed to the current version, resulting in a technically impressive product. Moreover, Linux is highly modular and easily configured. This makes it easy to squeeze optimal performance from a variety of hardware platforms. Plus, with the source code available, vendors can tweak applications and utilities to meet specific requirements. Throughout this book, we will provide details of Linux kernel internals based on the most recent version, Linux 3.10, released in June of 2013.

Modular Monolithic Kernel Includes virtually all of the OS functionality in one large block of code that runs as a single process with a single address space All the functional components of the kernel have access to all of its internal data structures and routines Linux is structured as a collection of modules Loadable Modules Relatively independent blocks A module is an object file whose code can be linked to and unlinked from the kernel at runtime A module is executed in kernel mode on behalf of the current process Have two important characteristics: dynamic linking stackable modules Although Linux does not use a microkernel approach, it achieves many of the potential advantages of this approach by means of its particular modular architecture. Linux is structured as a collection of modules, a number of which can be automatically loaded and unloaded on demand. These relatively independent blocks are referred to as loadable modules. In essence, a module is an object file whose code can be linked to and unlinked from the kernel at runtime. The Linux loadable modules have two important characteristics: Dynamic linking: A kernel module can be loaded and linked into the kernel while the kernel is already in memory and executing. A module can also be unlinked and removed from memory at any time. Saves kernel memory. Stackable modules: The modules are arranged in a hierarchy. Individual modules serve as libraries when they are referenced by client modules higher up in the hierarchy, and as clients when they reference modules further down.

Figure 2.18 is an example that illustrates the structures used by Linux to manage modules. The figure shows the list of kernel modules after only two modules have been loaded: FAT and VFAT. Each module is defined by two tables, the module table and the symbol table. The module table includes the following elements: • * next: Pointer to the following module. All modules are organized into a linked list. The list begins with a pseudomodule (not shown in Figure 2.19 ). • * name: Pointer to module name • size: Module size in memory pages • usecount: Module usage counter. The counter is incremented when an operation involving the module’s functions is started and decremented when the operation terminates. flags: Module flags • nsyms: Number of exported symbols • ndeps: Number of referenced modules • * syms: Pointer to this module’s symbol table. • * deps: Pointer to list of modules that are referenced by this module. • * refs: Pointer to list of modules that use this module. The symbol table defines those symbols controlled by this module that are used elsewhere. Figure 2.18 shows that the VFAT module was loaded after the FAT module and that the VFAT module is dependent on the FAT module.

Figure 2.19 , taken from [MOSB02], shows the main components of the Linux kernel as implemented on an IA-64 architecture (e.g., Intel Itanium). The figure shows several processes running on top of the kernel. Each box indicates a separate process, while each squiggly line with an arrowhead represents a thread of execution. 4 The kernel itself consists of an interacting collection of components, with arrows indicating the main interactions. The underlying hardware is also depicted as a set of components with arrows indicating which kernel components use or control which hardware components. All of the kernel components, of course, execute on the processor but, for simplicity, these relationships are not shown.

Linux Signals Table 2.6 Some Linux Signals The kernel uses signals to call into a process. For example, signals are used to notify a process of certain faults, such as division by zero. Table 2.6 gives a few examples of signals. Table 2.6 Some Linux Signals

Table 2.7 Some Linux System Calls (page 1 of 2) System calls: The system call is the means by which a process requests a specific kernel service. There are several hundred system calls, which can be roughly grouped into six categories: file system, process, scheduling, interprocess communication, socket (networking), and miscellaneous. Table 2.7 defines a few examples in each category. • Processes and scheduler: tes, manages, and schedules processes. • Virtual memory: Allocates and manages virtual memory for processes. • File systems: Provide a global, hierarchical namespace for files, directories, and other file-related objects and provide file system functions. • Network protocols: Support the Sockets interface to users for the TCP/IP protocol suite. • Character device drivers: Manage devices that require the kernel to send or receive data one byte at a time, such as terminals, modems, and printers. • Block device drivers: Manage devices that read and write data in blocks, such as various forms of secondary memory (magnetic disks, CD-ROMs, etc.). • Network device drivers: Manage network interface cards and communications ports that connect to network devices, such as bridges and routers. • Traps and faults: Handle traps and faults generated by the processor, such as a memory fault. • Physical memory: Manages the pool of page frames in real memory and allocates pages for virtual memory. • Interrupts Handle interrupts from peripheral devices. Table 2.7 Some Linux System Calls (page 1 of 2)

Table 2.7 Some Linux System Calls (page 2 of 2)

Android Operating System A Linux-based system originally designed for touchscreen mobile devices such as smartphones and tablet computers The most popular mobile OS Development was done by Android Inc., which was bought by Google in 2005 1st commercial version (Android 1.0) was released in 2008 Most recent version is Android 4.3 (Jelly Bean) The Open Handset Alliance (OHA) was responsible for the Android OS releases as an open platform The open-source nature of Android has been the key to its success The Android operating system is a Linux-based system originally designed for touchscreen mobile devices such as smartphones and tablet computers. It is the most popular mobile OS by a wide margin: Android handsets outsell Apple’s iPhones globally by about 4 to 1 [VANC13]. But this is just one element in the increasing dominance of Android: Increasingly, it is the OS behind virtually any device with a computer chip other than servers and PCs. Android is becoming the standard OS for the “Internet of things,” a term that refers to the expanding interconnection of smart devices, ranging from appliances to tiny sensors. Initial Android OS development was done by Android, Inc., which was bought by Google in 2005. The first commercial version, Android 1.0, was released in 2008. As of this writing, the most recent version is Android 4.3 (Jelly Bean). In 2007, the Open Handset Alliance (OHA) was formed. OHA is a consortium of 84 firms to develop open standards for mobile devices. Specifically, OHA is responsible for the Android OS releases as an open platform. The open-source nature of Android has been the key to its success.

Android is defined as a software stack that includes the OS kernel, middleware, and key applications. Figure 2.20 shows the Android software architecture in some detail. Thus, Android should be viewed as a complete software stack—not just an OS. In a sense, Android is a form of embedded Linux. However, it provides much more than just the embedded kernel functionality, as Figure 2.20 illustrates. All the applications that the user interacts with directly are part of the application layer. This includes a core set of general-purpose applications, such as an e-mail client, SMS program, calendar, maps, browser, contacts, and other applications commonly standard with any mobile device. Applications are typically implemented in Java. A key goal of the open-source Android architecture is to make it easy for developers to implement new applications for specific devices and specific end user requirements. Using Java enables developers to be relieved of hardware specific considerations and idiosyncrasies, as well as tap into Java’s higher-level language features, such as predefined classes. Figure 2.20 shows examples of the types of base applications found on an Android platform.

Application Framework Provides high-level building blocks accessible through standardized API’s that programmers use to create new apps architecture is designed to simplify the reuse of components Key components: Activity Manager Manages lifecycle of applications Responsible for starting, stopping, and resuming the various applications Window Manager Java abstraction of the underlying Surface Manager Allows applications to declare their client area and use features like the status bar Package Manager Installs and removes applications Telephony Manager Allows interaction with phone, SMS, and MMS services The Application Framework layer provides high-level building blocks, accessible through standardized APIs, that programmers use to create new apps. The architecture is designed to simplify the reuse of components. Some of the key Application Framework components are: • Activity Manager: Manages lifecycle of applications. It is responsible for starting, stopping, and resuming the various applications. • Window Manager: Java abstraction of the underlying Surface Manager. The Surface Manager handles the frame buffer interaction and low-level drawing, whereas the Window Manager provides a layer on top of it, to allow applications to declare their client area and use features like the status bar. • Package Manager: Installs and removes applications • Telephony Manager: Allows interaction with phone, SMS, and MMS services

Application Framework (cont.) Key components: (cont.) Content Providers these functions encapsulate application data that need to be shared between applications such as contacts Resource Manager manages application resources, such as localized strings and bitmaps View System provides the user interface (UI) primitives as well as UI Events Location Manager allows developers to tap into location-based services, whether by GPS, cell tower IDs, or local Wi-Fi databases Notification Manager manages events, such as arriving messages and appointments XMPP provides standardized messaging functions between applications • Content Providers: These functions encapsulate application data that need to be shared between applications, such as contacts. Resource Manager: Manages application resources, such as localized strings and bitmaps • View System: Provides the user interface (UI) primitives, such as Buttons, listboxes, date pickers, and other controls, as well as UI Events (such as touch and gestures) • Location Manager: Allows developers to tap into location-based services, whether by GPS, cell tower IDs, or local Wi-Fi databases • Notification Manager: Manages events, such as arriving messages and appointments • XMPP: Provides standardized messaging (also, Chat) functions between applications

System Libraries Collection of useful system functions written in C or C++ and used by various components of the Android system Called from the application framework and applications through a Java interface Exposed to developers through the Android application framework Some of the key system libraries include: Surface Manager OpenGL Media Framework SQL Database Browser Engine Bionic LibC The layer below the Application Framework consists of two parts: System Libraries and Android Runtime. The System Libraries component is a collection of useful system functions, written in C or C++ and used by various components of the Android system. They are called from the application framework and applications through a Java interface. These features are exposed to developers through the Android application framework. Some of the key system libraries include the following: • Surface Manager: Android uses a compositing window manager similar to Vista or Compiz, but it is much simpler. Instead of drawing directly to the screen buffer, your drawing commands go into off-screen bitmaps that are then combined with other bitmaps to form the display the user sees. This lets the system create all sorts of interesting effects such as see-through windows and fancy transitions. • OpenGL: OpenGL (Open Graphics Library) is a cross-language, multiplatform API for rendering 2D and 3D computer graphics. OpenGL/ES (OpenGL for embedded systems) is a subset of OpenGL designed for embedded systems. • Media Framework: The Media Framework supports video recording and playing in many formats, including AAC, AVC (H.264), H.263, MP3, and MPEG-4. • SQL Database: Android includes a lightweight SQLite database engine, for storing persistent data. SQLite is discussed in a subsequent section. • Browser Engine: For fast display of HTML content, Android uses the WebKit library, which is essentially the same library used in Safari and iPhone. It was also the library used for the Google Chrome browser until Google switched to Blink. • Bionic LibC: This is a stripped-down version of the standard C system library, tuned for embedded Linux-based devices. The interface is the standard Java Native Interface (JNI).

Every Android application runs in its own process with its own instance of the Dalvik virtual machine (DVM) DVM executes files in the Dalvik Executable (.dex) format Component includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language To execute an operation the DVM calls on the corresponding C/C++ library using the Java Native Interface (JNI) Android Runtime Every Android application runs in its own process, with its own instance of the Dalvik virtual machine (DVM). The DVM executes files in the Dalvik Executable (.dex) format, which is optimized for minimal memory footprint and efficient processor usage. The DVM is examined in Chapter 14. The Android Runtime component includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language. To execute an operation, the DVM calls on the corresponding C/C++ library using the JNI.

It is useful to illustrate Android from the perspective of an application developer, as shown in Figure 2.21. This system architecture is a simplified abstraction of the software architecture shown in Figure 2.20. Viewed in this fashion, Android consists of the following layers: • Applications and Framework: Application developers are primarily concerned with this layer and the APIs that allow access to lower-layer services. • Binder IPC: The Binder Inter-Process Communication mechanism allows the application framework to cross process boundaries and call into the Android system services code. This basically allows high-level framework APIs to interact with Android’s system services. • Android System Services: Most of the functionality exposed through the application framework APIs invokes system services that in turn access the underlying hardware and kernel functions. Services can be seen as being organized in two groups. Media services deal with playing and recording media. System services deal with system functions visible to the application. • Hardware Abstraction Layer (HAL): The HAL provides a standard interface to kernel-layer device drivers, so that upper-layer code need not be concerned with the details of the implementation of specific drivers and hardware. The HAL is virtually unchanged from that in a standard Linux distribution. • Linux Kernel: Linux kernel is tailored to meet the demands of a mobile environment.

Activities An activity is a single visual user interface component, including things such as menu selections, icons, and checkboxes Every screen in an application is an extension of the Activity class Use Views to form graphical user interfaces that display information and respond to user actions An activity is a single visual user interface component, including things such as menu selections, icons, and checkboxes. Every screen in an application is an extension of the Activity class. Activities use Views to form graphical user interfaces that display information and respond to user actions. We discuss Activities in Chapter 4.

Power Management Alarms Wakelocks Implemented in the Linux kernel and is visible to the app developer through the AlarmManager in the RunTime core libraries Implemented in the kernel so that an alarm can trigger even if the system is in sleep mode this allows the system to go into sleep mode, saving power, even though there is a process that requires a wake up Prevents an Android system from entering into sleep mode These locks are requested through the API whenever an application requires one of the managed peripherals to remain powered on An application can hold one of the following wakelocks: Full_Wake_Lock Partial_Wake_Lock Screen_Dim_Wake_Lock Screen_Bright_Wake_Lock Android adds two features to the Linux kernel to enhance the ability to perform power management: alarms and wakelocks. The Alarms capability is implemented in the Linux kernel and is visible to the app developer through the AlarmManager in the RunTime core libraries. Through the AlarmManager, an app can request a timed wake-up service. The Alarms facility is implemented in the kernel so that an alarm can trigger even if the system is in sleep mode. This allows the system to go into sleep mode, saving power, even though there is a process that requires a wake up. The wakelock facility prevents an Android system from entering into sleep mode. An application can hold one of the following wakelocks: • Full_Wake_Lock: Processor on, full screen brightness, keyboard bright • Partial_Wake_Lock: Processor on, screen off, keyboard off • Screen_Dim_Wake_Lock: Processor on, screen dim, keyboard off • Screen_Bright_Wake_Lock: Processor on, screen bright, keyboard off These locks are requested through the API whenever an application requires one of the managed peripherals to remain powered on. If no wakelock exists, which locks the device, then it is powered off to conserve battery life. These kernel objects are made visible to apps in user space by means of /sys/ power/wavelock files. The wake_lock and wake_unlock files can be used to define and toggle a lock by writing to the corresponding file.