2-3. 운영체제 구조

운영체제 설계 및 구현

이번에는 운영체제를 설계하고 구현할 때 우리가 당면하는 문제점을 논의한다. 물론 이런 설계 시 문제점에 대한 완전한 해결책은 없지만 성공적인 접근 방법들이 있다. 시스템을 설계하는데 있어 가장 크다고 할 수 있는 문제점은 시스템의 목표와 명세를 정의하는 일이다. 이런 목표와 명세는  하드웨어와 시스템 유형으로 어떤 것을 선택하는지에 영향을 받는다. 일괄처리, 시분할, 단일 사용자, 다중 사용자, 분산, 실시간 등 여러 유형의 시스템이 있기 때문에 목표와 요구명세를 정의하는 것이 어렵다고 하는 것이다. 

한줄 요약=> 운영체제에 대한 요구 정의 문제를 해결하는 유일한 해법은 없다.

원래 이런 분야는 소프트웨어 공학에서 다루는 것이므로 지금은 이정도만 하고 넘어가도록 한다.

하지만 운영체제 설계 시에 한 가지 중요한 원칙이 있는데 바로 메커니즘으로부터 정책을 분리하는 것이다. 

메커니즘 : 어떤 일을 어떻게 할 것인가를 결정하는 것

정책 : 무엇을 알 것인가를 결정하는 것

메커니즘으로부터 정책을 분리하는 것이 왜 중요하냐면, 정책을 변경해야하는 경우에 정책 밑에 깔린 모든 메커니즘의 변경이 요구되기 때문이다. 예를 들어 타이머 구조는 CPU 보호를 보장하기 위한 메커니즘이지만, 특정 사용자를 위해 타이머를 얼마나 오랫동안 설정할지를 결정하는 것은 정책적 결정이다. 타이머를 설정한다고 CPU보호가 불가능하면 안 된다는 것이다.

운영체제 구조

현대의 운영체제와 같이 크고 복잡한 시스템은 변경을 쉽게 하도록 신중히 제작되어야 한다. 때문에 운영체제의 구조가 잘 설계 되어있어야 변경이 쉽고, 적절하게 동작한다. 이 절에서는, 운영체제의 구조 4가지를 살펴 볼 것이다.

1. 간단한 구조

잘 정의된 구조를 갖지 못한 상용 시스템이 많이 있다. 종종 그러한 운영체제는 처음에는 소형이면서 간단하고 제한된 시스템으로 시작되어서 그런 구조여도 문제가 없었지만, 점점 시스템이 커지면서 문제가 된 것이다. 그러한 예로 MS-DOS가 있다.

< MS-DOS 계층 구조 : 인터페이스와 기능 계층이 잘 분리되어 있지 않다.>

MS-DOS는 인터페이스와 기능 계층이 잘 분리되어 있지 않는데, 최소의 공간에 최대의 기능들을 제공하도록 작성되어 있어서, 모듈로 분할되지 않았다. 변경을 하고자 하는 경우 모듈이 아니기 때문에 전체적인 수정이 필요할 수도 있다. 때문에 변경이 용이하지가 않은 것이다.

ex) MS-DOS의 응용 프로그램은 디스플레이와 디스크에 직접 쓰기가 가능하다. 이런 자유는 바이러스와 같은 악의적인 프로그램으로부터 취약하게 만들었다. 따라서 사용자 프로그램이 문제가 생기면 시스템 전체가 고장 나게 된다.

MS-DOS와 같이 제한적인 구조의 또 다른 예는 UNIX 운영체제이다. 초기의 유닉스는 다음 그림과 같이 계층들로 이루어졌다고 볼 수 있다.(현재는 발전하면서 추가/확장된 것이다.)

< UNIX 시스템 구조 >

아래서 두 번째 층이 커널인데 층이라고 하기에는 너무 많은 기능이 들어있다. 계층들로 이루어져 있지만 간단하기 때문에 간단한 구조로 간주하는 듯하다.

2. 계층적 접근

운영체제 시스템은 여러 계층((layer, level)으로 구분된다.

- 최하위 계층(layer 0) : 하드웨어

- 최상위 계층(layer N) : 사용자 인터페이스

모듈화를 통해, 각 계층은 바로 아래 계층에서 제공하는 기능과 서비스만을 사용한다.

- 계층은 하위 계층에 대한 연산을 호출할 수 있다.

< 계층 구조의 운영체제 >

장점

- 구축과 디버깅의 단순함

- 설계와 구현이 단순하다

- 각 계층은 하위 계층에서 제공하는 연산만을 통해 구현된다

- 각 계층은 이 연산들이 어떻게 구현되는지 알 필요가 없다

단점

- 다양한 계층들이 대략적으로 정의된다

- 각 계층은 오직 하위 계층들에서 제공하는 기능만을 사용하기 때문에, 주의 깊은 계획이 요구된다 => 예로 예비 저장 장소를 위한 장치 드라이버는, 메모리 관리가 예비 저장 장소를 사용할 수 있는 능력을 필요로 하기 때문에 메모리 관리 루틴들보다 저수준에 있어야 한다.

3. 마이크로커널

커널을 가능한 한 경량화한다. 

- 많은 기능을 커널로부터 user space로 이동한다

- 커널과의 통신은 사용자 모듈 사이에서 메세지 전달을 통해 이루어진다

장점

- 마이크로 커널을 확장하기 쉽다

- 운영체제를 새로운 구조로 이식하기 쉽다

- 커널에서 수행되는 코드가 더 적으므로 더 안정적이고 더 안전하다

단점

- 커널 공간과 통신하기 위한 사용자 공간의 성능 오버헤드 발생

4. 모듈

대부분의 현대 운영체제는 커널 모듈을 구현한다

- 커널은 핵심 컴포넌트들로 이루어지며 부팅 시나 실행 시에 부가적인 서비스들을 동적으로 연결한다

- 객체 지향 접근을 샤용한다

- 각 핵심 컴포넌트는 나뉘어져 있다

- 각 컴포넌트는 정해진 인터페이스를 통해 다른 컴포넌트와 대화한다

- 각 컴포넌트는 커널내에서 필요에 따라 적재 가능하다

=>결론적으로, 계층 구조와 유사하나 더 유연하다.

< 솔라리스 모듈화 접근법 >

모듈화 커널 접근법은 계층구조 접근법과 유사하다

- 모듈화 커널 접근법은 서브시스템들이 서로 정해진 인터페이스를 통해 상호작용하도록 요구한다

하지만 계층적 커널은 하위 계층에 있는 서브시스템들이 상위 계층 연산의 호출을 허용하지 않는 엄격한 서브시스템의 순서를 가지고 있다. 반면 모듈화 커널 접근법에서는 이런 제약이 없어서 모듈들이 서로 자유롭게 호출할 수 있다.