[운영체제] 공룡책🦖 ch02. Operating-System Structures

Reference

1. Abraham Silberschatz, Greg Gagne, Peter B. Galvin - Operating System Concepts (2018)

2. Operating System class by Professor Sukyong-Choi at Korea University 

중요한 내용 위주로 요약 & 정리해 보았습니다.

2.1 Operating System Services

OS service

1. user에게 유용한 기능

• User interface : 사용자와 컴퓨터의 연결 지점
• Program execution : 프로그램을 메모리에 로드하고 실행, 종료
• I/O operations : 사용자가 직접 제어x, 입출력 명령으로 I/O 방법 제공
• File-system manipulation : I/O, 조작, 권한 관리
• Communications : process간 통신 (1. shared memory) (2. message passing)
• Error detection : 오류 탐지 및 수정, 종류에 따른 처리 진행

 

   2.  system 자체적으로 효율적인 운영을 위한 기능

• Systems with multiple processes can gain efficiency
• Resource allocation : 효율적인 CPU 사용을 위해 CPU 속도, 실행돼야 하는 프로세스, core 수 등을 고려하여 CPU 스케줄링 진행
• Logging : 어떤 프로그램이 어떤 자원을 얼마나 사용하는가
• Protection and security : 자원 접근 통제, 외부 침입에 대한 인증 요구

 

2.2 User and Operating System Interface

• Command-line interface(CLI or command interpreter)
• Graphical user interface(GUI)

 

2.2.1 Command Interpreters

• 사용자-지정 명령을 처리
• 파일 조작
• 구현 방법

1. 명령 해석기 자체가 명령어를 실행할 수 있는 코드를 내장
2. 명령을 실행하는 파일(프로그램)이 별도로 존재하고 이를 호출해서 실행
3. 이 경우 프로그래머가 system에 새로운 명령어를 추가하기 쉽다.

Ex) UNIX command [rm file.txt] → rm 파일을 찾아 메모리에 load후 parameter file.txt를 실행

 

2.3 System Calls

System call : OS 서비스에 대한 인터페이스를 제공하는 역할

System call table : 특정 system call에 할당된 동작들이 있고, 이것들이 모인 곳 (interrupt vector)

system call은 kernel과 user program을 이어주는 interface 역할을 합니다.

 

2.3.1 example

예를 들어 user program이 파일을 열 때, 시스템에 접근하기 위해서는 kernel mode로 전환되어야 하고, 여러 동작들을 수행하기 위해서는 system call이 여러 번 호출됩니다. (sequence of system call)

그 후 실제 I/O 처리가 이뤄지고 후처리 과정을 거칩니다.

 

System call sequence

 

2.3.2 Application Programming Interface (API)

단순한 프로그램도 OS의 기능을 많이 사용하는데, 그러면 수많은 system call을 호출합니다.

이때, 개발자가 system call을 직접 처리하는 대신에, 우리가 사용할 수 있는 함수들의 집합인 API를 사용합니다.

os가 제공하는 라이브러리를 통해서 API를 사용합니다.

API를 구성하는 함수들이 개발자를 대신하여 실제 system call을 하게 됩니다.

 

Most common API

• Window, POSIX, Java API

 

Example read() in UNIX/Linux

 

API 장점

• program portability (이식성) : 동일한 API를 사용하면 어떤 시스템에서라도 complie & run
• 실제 system call은 정교하여 다루기 어려우므로 편리한 API를 사용함

 

RTE (run-time environment)

• 특정 프로그래밍 언어로 쓰여진 application을 수행하기 위한 software 집합
• system-call interface 제공 : OS가 제공하는 system call에 대한 연결점
• API 함수 호출이 일어나면 이를 가로채서 필요한 OS System call을 호출함
• System call에 대한 번호가 있고, 이에 따라 index된 테이블을 유지함
• System call interface는 system call의 상태 정보를 return

 

 

System Call Implementation

 

OS에게 parameter 전달 방식

1. register 이용
2. memory block 이용 : 메모리 내 block이나 table에 저장 → 그 시작 주소를 register에 parameter로 전달
3. 조합 : parameter의 수에 따라 register or block method 사용

 

Parameter Passing via Table

 

Standard C Library Example

C 프로그램에서 printf()를 호출하게 되면, C library가 해당 호출을 가로채고, OS에게 necessary system call을 호출합니다. write()가 return한 값을 받아서 다시 user program에게 전달합니다.

 

2.3.3 Types of System Calls - 6종류

1. Process Control
2. File management
3. Device management
4. Information maintenance
5. Communications
6. Protection

 

2.3.3.1 Process Control

• Program → 정상 end() /비정상 abort()
• 정상/비정상적 상황에서, 제어는 command interpreter로 무조건 전달함
• process가 다른 program을 load() / excute()
• 프로세스 생성, 종료, 복제
• 생성된 프로세스의 실행 종료를 기다림
• 특정 시간만큼 기다림 (sleep)
• 특정 event을 기다리거나, 일으킴 (signal)
• 메모리를 할당하거나 해제 (allocate)
• 공유 데이터 잠금/해제

 

 

2.3.3.5 Communication

process 간 통신 방식에는 다음 두 가지가 있습니다.

1. message passing model : Mailbox를 통한 message 교환
2. shared-memory : 공유 memory 영역을 이용

 

Message Passing Model

• Mailbox를 통한 message 교환
• connection 후 통신
• 상대의 이름(id)을 알아야 통신 가능
• 충돌이 없고 구현이 더 쉬움

 

Shared-Memory Model

• 공유 영역에 읽기/쓰기 함으로써 정보 교환
• 동시에 같은 위치에 기록하지 않아야 함
• 컴퓨터 내에서 메모리 전송 속도로 수행하기 때문에, 속도 빠르고 통신이 편리
• process간 보호와 동기화에서의 문제가 발생

 

2.5 Linkers and Loader

program은 disk 상에서 binary executable file로 저장됩니다.

이런 program을 memory에 load한 후 process로 배치합니다.

이는 아래와 같은 과정을 따릅니다.

1. compiler : source program → object file / 소스 코드를 바이너르 코드로 변환
2. linker : object file → executable file / relocatable object file들을 연결하여 single binary executable file로 변환하는 역할
3. loader : executable file → program in memory / executable file을 memory에 적재하는 역할

• ./main : fork() 시스템 콜을 통해서 새로운 process가 생성
• build = source program이 compiler와 linker를 거쳐 executable file이 되는 과정
• dll(dynamically linked libraries) = program 중에서 기본적으로 실행하지 않고 사용자가 요청할 때, 실행 중간에 동적으로 link된다. 여러 process들이 DLL을 공유하여 메모리를 절약한다.
• object file = 컴파일, 어셈블러를 통해 변환된 파일 (기계어), relocatable object file(ELF 포맷)

 

2.6 Why Applications Are Operating-System Specific

특정 OS에서 컴파일된 application은 다른 OS에서 실행이 불가능합니다.

이는 OS가 고유의 system call 집합을 제공하기 때문입니다.

 

Application이 여러 OS에서 사용 가능하도록 하려면?

1. interpreter 언어로 작성한다. (interpreter는 여러 OS에서 사용 가능)

• Interpreter의 경우 소스 프로그램의 각 line을 읽어서, 상응하는 유사 기계어를 실행하고, OS call을 호출한다.
• 단점 : 기계어로 구성된 것보다 성능이 떨어진다. Interpreter가 OS의 일부 기능만 제공한다.

1. 가상 머신을 포함한 언어로 작성한다. (Java)

• Java RTE는 java 응용을 java 가상 머신으로 load하기 위한 요소들을 포함
• 이러한 RTE가 많은 IS에 이식되어 어떤 java 응용이던지 RTE 내에서 실행 가능하다.
• 단점 : 성능 저하 문제

1. 표준 언어나 API를 사용한다.

• 어디서든 컴파일이 가능하다
• 단점 : 실행될 OS에서 port되어야 함→ 시간 소요

 

2.7 Operating System Design and Implementation

2.7.2 Mechanisms and Policies (기법과 정책)

• Mechanism : 기법, 어떻게 할 것인가
• Policies : 운영상 정책/수단, 무엇을 할 것인가

⇒ 기법과 정책을 분리함으로써 융통성이 생긴다. (여러 정책에서 사용될 수 있는 기법)

ex) 프로그램 유형에 따라서 우선 순위를 부여하는 기법, 자원 할당 여부를 결정할 때 마다 정책 필요

예를 들어서 CPU protecting의 경우, Timer mechanism을 사용하고, 사용자 별로 타이머 시간을 다르게 설정하는 식으로 구현합니다.

 

2.8 Operating System Structure

운영체제가 제대로 동작하고 쉽게 수정이 되도록 하기 위해서 main 함수에 전체 코드를 넣는 대신, 여러 함수로 로직을 분리해야 합니다.

 

2.8.1 Monolithic Structure (Tightly coupled system)

• 커널의 모든 기능을 single, static binary 파일에 넣음
• 단일 주소 공간에서 실행됨
• ex) original unix os

⇒ 커널의 너무 많은 기능이 단일 주소 공간으로 결합됨

• The Linux OS (UNIX 기반, 변형)

⇒ Kernel 부분이 구분됨, module식 설계이지만 통채로 memory에 올라서 실행됨

 

장점

• 구조가 단순
• 구현, 확장이 어려움
• system-call interface에서 overhead가 거의 없고, kernel 내 통신이라 빠름 (한 번에 메모리로)
• 속도/효율성 때문에 여전히 사용되는 구조

 

2.8.2 Layered Approach (Loosely coupled system)

• System이 개별적인 작은 요소들로 분리됨
• 모든 요소들이 kernel을 구성
• Module 식 설계의 한 방법이다.

• OS 계층은 data와 operation으로 구성되는 ‘추상화 객체의 구현’
• 상위 계층 M은 하위 계층의 연산(기능)을 호출함
• 계층 M은 상위 계층에서 호출되는 data/function으로 구성됨

 

장점 - construction과 debugging의 간편함

• Layer 0에서는 hardware가 정확하다고 가정함 ⇒ 다른 부분은 신경 쓰지 않고 디버깅 할 수 있다.
• 단계별로 이전/하위 단계가 정확하게 동작한다고 가정
• error 발견했다면 해당 층에서의 문제이다.
• 계층별로 이전/하위 계층에서 제공하는 연산이 어떻게 동작하는지는 몰라도 됨
• 각 계층은 상위 계층에 특정 정보들을 숨김

 

단점 - Pure layered approach 방식의 OS는 잘 사용되지 않는다.

• 적절한 계층별 기능 정의가 어렵다
• 전체적 성능 저하

⇒ 계층을 줄여서 모듈화 코드의 장점을 제공하면서 문제점을 피하자!

 

 

2.8.3 Micorkernels

 

Smaller kernel(Mach) - Microkernel 접근 방식으로 커널을 모듈화함

• 중요하지 않은 요소는 커널에서 제거하고, 별도의 주소 공간에 존재하는 user level program으로 구현
• 통신 기능 외에, 최소한의 프로세스/메모리 관리 기능을 제공함
• Message passing을 통한 간접적인 통신을 제공

 

장점

• OS 확장이 쉽다 - 새로운 service는 user space에 추가, kernel은 수정이 불필요
• kernel에 대한 보안/신뢰성 제공 - 대부분의 service가 user process로 실행

 

단점

• 가중된 시스템 기능 부하로 인한 성능 문제
• 두 사용자 서비스 통신 → 서비스 간 메시지 복사(독립된 주소 공간)
• 메시지 교환을 위한 프로세스 간 전환(switch) 필요
• 메시지 복사/프로세스 간 전환이 microkernel 기반 OS의 성장에 장애가 됨

 

2.8.4 Modules → 현대적 OS 구현

Loadable kernel modules (LKMs)

• kernel은 핵심 요소들을 가지며, boot/run time 시 추가 서비스들은 모듈로 연결함
• kernel이 핵심 service 제공, 다른 service들은 kernel 실행 동안 동적으로 구현(실행 중 변경 가능)

Ex) CPU 스케줄링, 메모라 관리 ⇒ kernel에 직접 구현 // 파일 시스템 지원 ⇒ LKM으로 구현

 

Layerd system과 유사

• 각 kernel 영역이 defined, protected 인터페이스를 가짐
• 계층적 동작이 아닌, 임의의 다른 모듈을 호출 가능

 

Microkernel approach와 유사

• 주 모듈이 핵심 기능을 가지며, 다른 모듈을 적재하고 통신하는 방법을 앎
• message passing을 사용하지 않으므로 더 효율적임

 

Linux

• 리눅스는 device driver, file system 지원을 위해 LKM 사용
• LKM은 시스템 시작, 또는 실행 중에 kernel에 insert됨
• 필요한 driver가 없다면, 동적으로 적재 가능
• 동적 제거도 가능
• LKM을 허용하면서 monolithic system의 성능에서의 이점을 유지함