1. L1. Introduction

1.1. 운영체제란? | What is the Operating System?

1.1.1. 운영체제의 정의 | Definition of the Operating System

“A program that acts as an intermediary between a user of a computer and the computer hardware.” (컴퓨터 사용자와 컴퓨터 하드웨어 사이에서 중개자처럼 행동하는 프로그램)

A. Silberschatz

“Programs that make the hardware usable.” (컴퓨터 하드웨어를 운용 가능하게 하는 프로그램)

Dietel

운영체제 | operating system 에 대해 수용되는 정확한 정의는 없다.

다만, 가장 일반적인 정의는 컴퓨터가 동작하는 모든 시간 동안 실행되는 하나의 프로그램 으로 통상적으로 커널 | kernel 이라 부르는 그것이다.

그리고 이러한 kernel의 관점에서 모든 프로그램은

시스템 프로그램 | system programs
응용 프로그램 | application programs

의 두가지 타입으로 나뉜다.

1.1.2. 컴퓨터 시스템의 구조 | Computer System Organization

현대의 컴퓨터 시스템은 하나 이상의 CPU를 가지고, 컴퓨터의 구성요소들과 공유 메모리 사이의 접근경로를 제공해주는 버스 | bus 를 통해 다양한 장치와 연결되어 있다.

의 특징을 만족한다.

1.1.3. OS를 배우는 이유

새로운 하드웨어를 실행시키기 위함
기능성을 더하고, 조정하고, 향상시키기 위함
성능을 fine-tuning하기 위함

1.2. 운영체제의 목적 | Operating Systems Goals

리소스의 효율적인 운용 - 성능에 영향을 미치는 병목현상(bottlenecks)를 피한다. - 모든 구성요소를 가능한 바쁜 상태로 유지한다.
사용자의 편의성과 생산성 향상 - 사용자는 기계보다 더 많은 자원을 소모한다. - 기능(function)을 가능한 효율적으로 전달한다.
가용성 및 신뢰성 - 컴퓨터 시스템은 매우 중요하다. - 시스템의 오류는 회사의 오류로 이어진다.

1.3. 운영체제의 구조

1.4. 운영체제의 변화 | Evolution of Operating Systems

1.4.1. when OS wasn’t appeared…

배경 CPU ⇒ 진공관, memory ⇒ 마그네틱 코어, input ⇒ 펀치카드로 구성되어있었고, OS가 없었던 때에는 이들을 이용하기 위하여 사람이 수동으로 작업을 배치했어야 했다.
문제점 사람이 직접 실행될 프로그램의 Scheduling time을 예측하고 사용자에게 분배해야 하는데, 자칫 짧게 예측하면 해당 시간 내에 작업을 완료하지 못하고, 길게 예측하면 남는 시간동안 자원이 놀게되는 비효율성을 불러 일으켰다. 또한, 특정 프로그램을 실행시키기 위한 준비시간(setup-time)이 길어
Simple Batch Systems

1.5. 최신 컴퓨팅 패러다임 | Modern Computing Paradigms

Traditional computing - Number crunching
Web-based computing - Information processing
Embedded computing - Target-specific Hardware/Software systems - Example: handheld mobile devices - Limited memory - Slow processors - Small display screens - Battery

2. L2. Backgrounds & Preliminaries

2.1. I/O

2.1.1. I/O 장치란? | What is I/O Device?

컴퓨터가 외부와 통신할 수 있게 해주는 장치이다. 마우스, 키보드, 모니터, 스피커 등이 이에 해당된다.

이러한 I/O 장치는 기본적으로 시스템 Bus에 연결되어 있으며, 메모리에 직접적으로 접근할 수 없기에 CPU가 중개자 역할을 수행하여 처리한다.

2.1.2. 폴링 | Polling

I/O 장치는 자신의 정보를 status register에 저장하고 이를 CPU가 매 연산마다 계속 검사하여 데이터 입/출력이 가능 여부를 확인하는 방식이다.

하지만, 일반적으로 하드웨어 장치의 속도는 CPU의 연산 속도에 비해 매우 느리다. 그럼에도 polling 중에는 CPU가 다른 일을 하지 않고 주기적으로 하드웨어의 상태를 체크해야하므로 CPU의 낭비를 불러일으킨다.

2.1.3. 인터럽트 | Interrupt

I/O 작업이 필요할 때, 인터럽트 제어기를 통해 I/O 장치가 CPU에 Interrupt를 발생시킴으로써 사용 가능한 상황임을 통보하고 CPU는 이다음에 작업을 멈추고 Interrupt 처리를 진행하는 방식이다. 이때 CPU는 하드웨어장치가 동작중인 동안 해당 프로세스를 멈추고 다른 프로세스에 CPU를 양도한다. 하드웨어 장치의 처리가 끝나면 인interrupt가 발생하고 CPU는 운영체제가 미리 정의해 놓은 ISR(Interrupt Service Routine)혹은 Interrupt Handler를 실행한다. Interrupt Handler는 I/O를 대기중인 프로세스를 깨우는 등의 작업을 통해 해당 프로세스가 계속 작업을 이어갈 수 있도록 한다.

이렇게 하면 대기시간이 긴 디바이스의 경우 CPU가 의미없는 loop를 돌지 않아 효율적인 처리가 가능하지만, 높은 처리량을 요구하는 I/O 장치에서는 오버헤드 발생량이 증가한다. 만약 하드웨어 장치가 충분히 빠른 경우에는 오히려 interrupt를 처리하며 다른 프로세스로 전환하는 Context Switching 동안 많은 비용이 수반된다.

따라서 키보드, 혹은 마우스와 같이 대기시간이 긴 I/O 장치의 경우 인터럽트 방식을 사용한다.

2.1.4. DMA (Direct Memory Access)

디스크에서 데이터를 읽어 메모리에 적재하는 경우(즉, 다량의 데이터 이동이 발생하는 경우), 메모리에 엑세스 할 수 있는 장치는 CPU밖에 없기 때문에 이를 CPU가 계속 중개해야 하면 그만큼 interrupt 발생 횟수도 많아져 결국 오버헤드로 이어진다.(PIO | Programmed I/O)

따라서 CPU에서 입/출력 명령을 전달받으면 DMA 제어기가 메모리에 직접 입출력을 수행하여 CPU의 개입 없이 주변 장치에 데이터 전송이 가능하게 한다. 즉, DMA 제어기는 CPU에 메모리 버스를 통해 CPU와 통신하고 PCI Bus를 통해 다른 I/O 장치와 통신한다.

2.2. OS의 하드웨어 보호 | Hardware Protection for OS

적절히 디자인된 OS는 잘못된(어쩌면, 악의적인) 프로그램이 다른 프로그램의 부적절한 실행을 불러오지 않도록 보호해야 한다.

이러한 수많은 종류의 프로그램 결점에 대항하기 위해, OS는 User Mode 와 Kernel Mode로 구성되는 Dual Mode Mechanism을 가지고 있으며, Processor 또한 Protection Mechanism을 제공한다.

2.2.1. Dual Mode Operation

Processor는 적어도 다음의 두 가지 이상의 실행 모드를 하드웨어적으로 지원한다. (모든 표준 UNIX 커널은 오직 두가지 만을 가진다.)

User Mode 유저 영역에서 실행
Kernel Mode (감독관 모드 / 시스템 모드 / 모니터 모드) OS의 영역에서 실행

이러한 모드는 보호되고 있는 processor register의 상태 비트에 의해 결정되는데, 예를 들어 Intel 80x86 프로세서는 4가지 다른 실행 모드의 CPL(Current Privilege Level)을 특정하는 2비트 필드의 레지스터를 가지고 있다.

어떠한 장치들은 보호 설계를 통해 오직 kernel 모드에서만 동작하게 되어있다. 그렇다면 User Program은 어떻게 이러한 장치들에 접근할 수 있을까?

User Program이 privileged된 자원에 접근하려면 OS를 호출하여야만 한다. OS는 이후 kernel mode에서 실행중인 kernel service routine에 컨트롤을 넘기고, kernel이 이 요청이 적합하다고 판단하면 요청이 실행된다.

이러한 경우는 다음의 세가지 경우로 나뉜다.

Hardware Interrupt
Software interrupt (exception)
System Call

2.2.2. Operating System Services

User Services - Program execution 프로그램을 메모리에 로드하고 실행시키기 위한 시스템 가용성을 제공해야 한다. - I/O operations User Program은 I/O 연산을 직접적으로 실행하지 못하기 때문에, OS는 I/O를 수행할 수 있도록 하는 몇가지 수단을 제공해야 한다. - File-system manipulation 파일을 읽고, 쓰고, 만들고, 지우기 위한 프로그램 가용성을 제공해야 한다. - Communications 같은 컴퓨터 내 혹은, 네트워크로 연결된 다른 시스템의 프로세스 간 정보를 교환할 수 있어야 한다. - Error Detection CPU, 메모리, 하드웨어, I/O 장치, User Program의 오류를 감지하여 올바른 컴퓨팅을 보장해야 한다.
Resource allocation 같은 시각에 돌아가는 여러 유저들에게 자원을 적절히 할당해야 한다.
Accounting 계정별 과금 혹은 사용 통계 추적을 위해 어떤 유저가 어떤 컴퓨터 자원을 얼마나 소모하고 있는지 기록해야 한다.
Protection 시스템 자원에 대한 모든 접근이 컨트롤됨을 보장해야 한다.

2.2.3. System Call Interface

실행중인 프로그램과 OS사이를 연결하는 인터페이스를 말하며, 보통 함수를 호출함으로써 접근 가능하다.

2.2.4. System Call Principles

애플리케이션과 하드웨어 사이에 추가적인 layer를 집어넣는 것으로 다음과 같은 이점을 얻는다. - Easy to program 사용자, 프로그래머가 각각의 Hardware 장치에 따른 low-level 프로그래밍으로부터 자유롭다. - Increasing system security kernel이 요청의 적합성을 interface 레벨에서 판단할 수 있다. - Increase program portability
System calls - UNIX 시스템은 커널에서 지원하는 System calls를 통해, kernel service를 요청하기 위한 User Mode와 process, hardware 장치 간을 연결하는 대부분의 인터페이스를 지원한다.

2.2.5. POSIX APIs and System Calls

API (Application Programming Interface) - 특정 서비스를 얻는 방식에 대해 정의한 함수 ex) libc 내부에 구현된 API인 malloc(), calloc(), free() 함수는 brk() system calls를 이용한다. - 해당 기능이 어떻게 구현되어있는지와 관계없이 system이 애플리케이션에 적절한 APIs set를 제공하면 이를 “POSIX-compliant”라고 한다. - 프로그래머의 입장에서 보면 User Mode Libraries 같은것!
System Call - 소프트웨어의 interrupt로 부터 호출된 kernel로의 명시적 요청 - 어떠한 system call들은 하나 이상의 arguments를 요구한다. - 정수를 반환함 (실패하면 -1) - system call은 user space의 libc 내부에 wrapper function으로 구현되어 있다.

2.2.6. OS & System Programs

System Programs - 프로그램 개발과 실행을 위한 편의 환경을 제공한다. - 대부분의 유ㅜ저의 관점에서, OS는 실질적인 system call들이 아닌, 시스템 프로그램으로 정의되어 있다.
System program은 다음과 같이 분류 가능하다. - File manipulation - Status information - File modification - Programming language support - Program loading and execution - Application programs

2.2.7. OS Design

System Design 목표

  - User Goals OS는 사용하기에 편리하고, 배우기 쉬우며, 신뢰할 수 있으며, 안전하고, 빨라야 한다.
  - System Goals OS는 디자인, 구현, 유지가 쉬워야 하고, 유연하며, 신뢰할 수 있고, 에러가 없으며, 효율적이어야 한다.

Mechanisms and Polices

  - Mechanisms 어떻게 할 것인가?
  - Policies 무엇을 할 것인가?

Mechanism과 Policy의 분리는 매우 중요한 원리로, 나중에 policy를 변경하려는 경우에 최대한의 유연성을 보장해야 한다.

Layering Approach - OS는 상-하위의 몇개의 레이어(레벨)로 나뉜다. - 장점 - Modularity 각 레이어가 하위 레벨의 레이어의 함수와 서비스를 이용한다. - 시스템 인증과 디버깅이 쉽다. - 단점 - 레이어의 정의가 힘들다. - 명령이 실행되기 위하여 레이어 전체를 거처야 하므로 성능이 떨어진다.
System Implementation - 전통적으로 어셈블리어로 작성되었으나 이제 OS도 higher-level language로 작성 가능하게 되었다. - 하지만 성능을 위한 부분에서는 아직 어셈블리어가 포함됨

2.2.8. Microkernels

Monolithic Kernel - 모든 Operating System Service들은 하나의 큰 단일 커널 안에 구현된다. - 가상적으로 어떤 프로세스도 다른 프로세스를 부를 수 있다.
Micro Kernel - 오직 core OS 함수만이 커널 내에서 구현된다. - 덜 중요한 서비스와 애플리케이션은 microkernel에서 build되어 User Mode에서 실행된다. - Operating System Service는 독립적인 프로세스의 조합으로 이루어진다. - 사용자 모듈 간 통신은 메시지를 이용하여 이루어진다. - 장점 - 높은 확장성, 모듈성(유지력) 향상 - 디버깅하기 쉽고 효율적이다. - 단점 - 서비스 호출에 모드/프로세스 스위칭이 포함됨 - 중요한 System Service가 User Mode에서 실행됨

2.2.9. Virtual Machine

예전에는 프로그램의 실행이 ISA + OS 조합의 특정 플랫폼으로 한정되었다. 따라서 윈도우 플랫폼의 애플리케이션을 리눅스 등의 다른 프로그램에서 실행시킬 수 없었다.

이러한 real-platform에 대한 종속성을 제거하고 높은 차원의 이식성과 유연성을 얻어 소프트웨어의 cross-platform 적합성을 달성하기 위해 Virtual Machine(VM)이 생겨났다.

VM이 필요한 이유

  - 휴대성은 네트워크 컴퓨팅에 매우 중요하다. 특히 mobile, wireless-download 플랫폼 등 다양한 CPU/OS/Hardware/Devices에서 일관된 실행 환경을 구성할 수 있는 경우에 특히 유용하다.(Java VM, GVM, Brew, WIPI 등)
  - CPU 혁신은 오래된 인터페이스로 인해 자주 제한되었다. legacy x86 binary를 지원하지 못하는 새로운 CPU들은 결국 시장을 점유하지 못했다.
  - 하나의 H/W에 대한 하나의 OS는 보안 허점을 초래할 수 있다. 하나의 서버에 여러 사용자가 연결된 경우 한 OS의 보안 허점으로 인해 모든 사용자가 보안 취약점에 노출된다.
  - 개발 과정에서 불안정한(신뢰할 수 없는)OS를 Sandbox 위에서 실행시킬 수 있다. 이는 OS개발 과정에서 빠른 디버깅과 재시작을 제공함으로써 큰 이점을 가져다 주었다.

VM Solution

  - 가상화를 위해 소프트웨어 레이어에 구현
  - 가상화를 위해 가상의 guest 시스템을 실제 host 시스템 위에 구현

Two types of VM

  - Process VM 각각의 프로세스를 가상화 (리눅스 앱을 윈도우로 포팅)
  - System VM 리눅스 OS를 윈도우 OS 위에서 가상화

Process VM

  - 서로 다른 ISA 또는 OS에서 프로그램이 실행가능하게 함
  - 실제 VM은 ABI(Application Binary Interface; user-level instructions & System calls)를 에뮬레이션
  - Runtime에서 Call 됨

System VM - 전체 OS를 구동 - 실제 VM이 모든 ISA를 에뮬레이션 - VMM 혹은 Hypervisor로 불림 - 종류 - Hosted - host OS위에서 실행 - H/W 상호작용을 위해 hostOS에 의존함 - Stand-alone - 순수한 하드웨어 위에서 작동 - 모든 H/W 상호작용은 VMM 자체적으로 해결 - 매우 효율적

2.2.10. 리눅스 | Linux

Unix-like OS
순수한 UNIX kernel을 사용 - UNIX OS의 모든 애플리케이션이 있지는 않지만 원한다면 대부분 자유롭게 사용 가능
GNU 라이센스 기반의 오픈소스

3. L3. 프로세스 | Processes

Process

실행중인 프로그램의 instance (실행된 프로그램)

프로세스의 구성

Images - Code: 기계 명령어 - Data: 변수 - Stack: 함수 호출의 상태 - Heap: 동적 메모리
Process Context - Program context - 데이터를 담고있는 Data Registers - PC, SP 등 - Kernel Context - pid, gid, sid, environments - VM structures(paging tables) - openf iles - signal handlers

맛있는고슴도치

탐색기

Operating System