System Structure
운영체제는 규모가 매우 크고 복잡한 소프트웨어
- 설계 시 소프트웨어의 구조를 신중히 고려해야 함
좋은 설계를 통해 쉬워지는 것들
- 개발
- 수정 및 디버깅
- 유지 보수
- 확장
디자인 목표 중에 좋은 것이란?
- 설계하고자 하는 시스템의 목적과 관계가 있음
OS Design Principle
Policy
-
What will be done
-
Supposed to be higher level, and use mechanism
Mechanism
-
How to do something
-
E.g., Concrete Algorithms, Data Structures
Mechanism과 Policy를 분리 함으로써, 운영체제 설계를 보다 Module화 할 수 있음
Methods for Operating System Design
Layering
OS의 복잡도를 낮추기 위한 방안
Layer는 정의가 명확한(Well-Defined)함수들로 이루어짐
하나의 Layer는 인접한 Layer와만 통신
- 위, 아래에 인접한 Layer와만 통신하며, 2단계 이상 건너뛴 Layer와 직접적으로 통신하지 않음
설계의 복잡도를 낮출 수는 있지만, 그로 인해 Overhead가 발생함
- E.g., OSI 7 Layers
Layering Example
Modularity
Layering의 장점
- Layer의 수정이 다른 Layer와 독립적임
모듈성으로 인해 해당 Layer를 갈아 끼우기 좋음
불완전한 Layering
MS-DOS에서는 Layering 원칙을 무시한 Interface 호출로 인한 취약점이 존재했다.
Kernel 내의 모듈들
Linux의 모듈러 구조이다.
Kernel Designs
CPU의 2가지 이상의 실행 모드
-
System Protection을 위해서 필요
실행 Mode의 권한에 따라, 접근할 수 있는 메모리, 실행 가능한 명령어가 제한됨 -
각각의 Mode 별로 권한(Privilege)이 설정 됨
-
Hardware 지원이 필요
User Mode와 Kernel Mode
Kernel Mode
-
모든 권한을 가진 실행 Mode
-
OS가 실행되는 Mode
-
Previlege 명령어 실행 및 레지스터 접근 가능
User Mode
-
Kernel Mode에 비해 낮은 권한의 실행 Mode
-
어플리케이션이 실행되는 Mode
-
Privilege 명령어 실행 불가능
실행 Mode 전환(Execution Mode Switch)
- User Mode에서 실행 중인 Application이 Kernel Mode의 권한이 필요한 서비스를 받기 위한 방법이 필요
System Call
User Mode에서 Kernel Mode로 진입하기 위한 통로
- Kernel에서 제공하는 Protected 서비스를 이용하기 위해 필요
(Open, Write, Msgsnd, Shm)
User Program에서 필요에 따라서 System Call을 위해 사용할 매개변수를 레지스터에 저장한다. 이후 System Call에 매핑된 Syscall Num을 이용하여 System call을 호출한다.
Monolithic kernel
특징
-
Kernel의 모든 Service가 같은 주소 공간에 위치
-
애플리케이션은 자신의 주소 공간에 커널 코드 영역을 매핑하여 커널 서비스를 이용
-
H/W 계층에 관한 단일한 Abstraction을 정의
이를 사용하기 위해, 라이브러리나 애플리케이션에게 단일한(Monolithic) 인터페이스 제공
장점
- 애플리케이션과 모든 Kernel서비스가 같은 주소 공간에 위치하기 때문에, System call및 Kernel 서비스 간의 데이터 전달 시 Overhead가 적음
단점
- 모든 서비스 모듈이 하나의 바이너리로 이루어져 있기 때문에 일부분의 수정이 전체에 영향을 미침
- 각 모듈이 유기적으로 연결되어 있기 때문에 Kernel 크기가 커질 수록 유지/보수가 어려움
- 한 모듈의 버그가 시스템 전체에 영향을 미침
Micro Kernel
특징
-
Kernel service를 기능에 따라 모듈화 하여 각각 독립된 주소 공간에서 실행
-
이러한 모듈을 서버라고 하며, 서버들은 독립된 프로세스로 구현
-
Micro Kernel은 서버들 간의 통신(IPC)
애플리케이션의 서비스 콜 전달과 같은 단순한 기능만을 제공
장점
-
각 Kernel service가 따로 구현되어 있기 때문에 서로 간의 의존성이 낮음
Monolithic Kernel보다 독립적인 개발이 가능
Kernel의 개발 및 유지 보수가 상대적으로 용이 -
Kernel service 서버의 간단한 시작/종료 가능
불필요한 서비스의 서버는 종료 (Resource 확보) -
이론적으로 Micro Kernel이 Monolithic 보다 안정적
-
서버 코드가 Protected Memory에서 실행되므로, 검증된 S/W 분야에 적합
단점
- Monolithic Kernel보다 낮은 성능을 보임
독립된 서버들 간의 통신 및 Context Switching
Hypervisor
특징
-
가상화된 컴퓨터 H/W 자원을 제공하기 위한 관리 계층
Guest OS와 H/W 사이에 위치함
Guest OS-Hypervisor가 제공하는 가상화된 H/W 자원을 이용하는 운영체제 -
각 Guest OS들은 각각 서로 다른 가상 머신(VMs)에서 수행되며, 서로의 존재를 알지 못함
H/W에 대한 접근은 Hypervisor에게 할당 받은 자원에 대해서만 수행 -
Hypervisor는 각 Guest OS간의 CPU, 메모리, 등 시스템 자원을 분배하는 등 최소한의 역할을 수행
장점
-
하나의 물리 컴퓨터에서 여러 종류의 Guest OS의 운용이 가능
한 서버에서 다양한 서비스를 동시에 제공 -
실제의 컴퓨터가 제공하는 것과 다른 형태의 명령어 집합 구조(Instruction Set Architecture)를 제공
단점
- H/W를 직접적으로 사용하는 다른 OS에 비해 성능이 떨어짐
반가상화(Para-Virtualization)로 성능저하 문제를 해결하려 함
Mono VS. Micro VS. Hypervisor
