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 예시

Layering의 장점

Layer를 수정 시 다른 Layer들과 독립적으로 디자인되어 있어서 그것만 고치면 됨.

-> modularity와 비슷한데 다른 부분은 modularity는 기능별, Layering은 그저 수직적으로 계층별로 나누는 것임.

불완전한 Layering

Layering의 원칙을 무시한 interface의 호출 시 OS 전체의 디자인이 엉킬 수 있기에 지양해야 함.

ex) MS-DOS-> interface가 잘 나뉘어져 있지 않았음.

 

2. Modularity

: 각 기능별로 모듈화.

- 각 모듈들은 계층화 되어있음. 즉, 각 계층들엔 여러 기능에 따른 모듈들이 있다.

Modularity 예시. 3개의 계층이 있고 각 계층 내에는 모듈들이 존재함.

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에 비해 성능이 떨어짐.