3. OS의 구조2
System Structure
운영체제는 규모가 매우 크고 복잡한 SW이다.
∴ 설계 시 'SW 구조'를 신중히 고려 필요.
좋은 설계 시...
1. 개발 시 편리함.(Develop)
2. 수정 및 디버깅 easy.(Modify&Debug)
3. 유지 보수가 쉬움.(Maintain)
4. 확장성이 좋아짐.(Extend)
OS의 Design Priciple(디자인 원칙)
1. Policy : OS가 무엇이 되게 할 것인가.
2. Mechanism: 어떻게 그것을 제공할 것인가.
-> 이렇게 Policy와 Mechanism을 분리함으로서 OS 설계를 보다 모듈화할 수 있음.
OS 설계를 위한 방법
1. Layering
: OS 설계의 복잡도를 낮추기 위한 방안
- 각 Layer는 Well-defined 함수들로 이루어짐.
- 1 Layer -> 인접한 Layer와만 통신(2단계 이상 건너뛴 Layer와는 직접적으로 통신하지 않음.)
하지만...!!
설계의 복잡도는 낮출 수 있지만 이로 인한 오버헤드가 발생함.
ex) OSI의 7계층-> 계층을 나눌 수 있어서 쉽게 이해, 파악, 설계 but 이로 인한 오버헤드가 많음.
Layering의 장점
Layer를 수정 시 다른 Layer들과 독립적으로 디자인되어 있어서 그것만 고치면 됨.
-> modularity와 비슷한데 다른 부분은 modularity는 기능별, Layering은 그저 수직적으로 계층별로 나누는 것임.
불완전한 Layering
Layering의 원칙을 무시한 interface의 호출 시 OS 전체의 디자인이 엉킬 수 있기에 지양해야 함.
ex) MS-DOS-> interface가 잘 나뉘어져 있지 않았음.
2. Modularity
: 각 기능별로 모듈화.
- 각 모듈들은 계층화 되어있음. 즉, 각 계층들엔 여러 기능에 따른 모듈들이 있다.
OS가 제공하는 실행 모드
두가지 이상의 실행 모드가 있는데...
User Mode, Kernel Mode, ...
- System 보호를 위해서 필요함.
(실행 모드의 권한에 따라서 접근 가능한 메모리와 실행 가능한 명령어가 제한됨.)
실행 모드 왜 나눔??
커널을 보호하기 위함.(User Mode에서 실행 중인 프로그램은 Kernel Mode 권한이 필요한 작업 불가능)
- 각 Mode 별로 권한이 설정됨.
User Mode
: 어플리케이션들이 실행되고 있는 모드
- Kernel 모드에 비해 낮은 권한의 실행 모드임.
- Kernel 메모리, 공유되지 않은 다른 프로세스의 메모리에 접근 불가능함.
Kernel Mode(= Privilege 모드)
: 모든 권한을 가진 모드
- HW에 직접적인 컨트롤이 가능함.
- OS의 Kernel이 실행되는 모드임.
- Privilege 명령어 실행 및 레지스터 접근 가능함.
하나의 프로세스에는 VM space가 있음.
이 안에는 이 프로세스를 통해서 실행하고자 하는 User Application( 코드, 데이터, 라이브러리)까지 모두 있음.
게다가 Kernel(코드, 텍스트 섹션, 메모리)도 있음.
∴ 프로세스가 Kernel 코드를 실행해야 할 때는 VM space에 있는 Kernel 코드를 실행함.
이때...!
Kernel Mode로 실행 모드를 전환하기 위해서 권한을 받는 방법이 필요함.
User가 Kernel에게 시스템콜(System Call)을 하고 이에 Kernel이 결과값을 리턴해 줌.
시스템 콜(System Call)
: User 모드에서 Kernel 모드로 전환하기 위한 통로.
ex) Open, Write, ...
User 프로그램에서 Kernel mode를 사용해야 할 때 OS에 call을 하는 방법이 필요했고 반대로 OS에서 Kernel 모드의 작업을 수행 후 값을 리턴해줄 수단이 필요했음.
커널의 구조
커널의 디자인
1. Monolithic Kernel
ex) Windows, Linux,...
- 커널의 모든 Service가 같은 주소 공간에 위치함.
- 어플리케이션은 주소 공간에 커널 코드 영역을 매핑함으로서 커널 서비스를 이용할 수 있음.
- HW 계층에 관한 단일 Abstraction을 정의 -> ∴ 라이브러리, 어플리케이션에게 동일한 인터페이스를 제공해 줌.
[장점]
- 어플리케이션과 모든 커널 서비스가 같은 주소 공간에 위치 ∴시스템 콜 및 커널 서비스 간의 데이터 전달 시 오버헤드가 적음.
[단점]
- 모든 서비스 모듈이 하나의 바이너리로 이루어짐 ∴ 일부분의 수정이 전체에 영향을 미침
- 각 모듈이 유기적으로 연결됨 ∴ 커널의 크기가 커질 수록 유지보수 Hard
- 한 모듈의 버그가 시스템 전체에 영향 끼침
2. Micro Kernel
- 커널 서비스를 기능에 따라 모듈화하여 각각 독립된 주소 공간에서 실행함.
즉, 핵심 기능의 커널은 공유하되 다른 커널 서비스 모듈들은 User Process처럼 사용함(서버).
- 서버들 간의 통신(IPC), 어플리케이션의 서비스 콜 전달 같은 단순 기능만 제공함.
[장점]
- 각 커널 서비스가 따로 구현 ∴ 서로 간의 의존성이 낮아서 독립적 개발, 개발 및 유지 보수가 상대적으로 easy
- 커널 서비스 서버의 쉬운 시작 및 종료 가능 ∴ 불필요한 서비스의 서버는 종료함으로서 많은 memory, CPU resource 확보 가능
- 이론적으로 Monolithic Kernel보다 안정적임.
- 서버 코드가 Protected Memory에서 실행 ∴ 검증된 SW분야에 적합.
[단점]
- Monolithic보다 낮은 성능임.
Monolithic Kernel VS Micro Kernel
3. Hypervisor
: 가상화된 컴퓨터 HW 자원을 제공하기 위한 관리 계층.
(마치 Virtual Box같은 기능.-> HW계층 위에 Hypervisor 위에 여러 OS)
- 각 게스트 OS들은 서로 다른 VM에서 수행되고, 서로의 존재를 모름.
- 각 게스트 OS 간의 CPU, Memory 등의 시스템 자원을 분배하는 최소한의 역할을 함.
[장점]
- 하나의 물리 컴퓨터에서 여러 게스트 OS 운용 가능
- 실제 컴퓨터가 제공하는 것과 다른 형태의 명령어 집합 구조 제공 가능
[단점]
- HW를 직접 사용하는 다른 OS에 비해 성능이 떨어짐.
