[운영체제] Chapter 2.7 Operating-System Design and Implementation

이 섹션에서, 우리는 운영체제를 설계하고 구현하는 데 직면한 문제를 논의한다. 물론, 이러한 문제에 완전한 해결책은 없지만, 성공적으로 증명된 접근방식이 있다.

2.7.1 Design Goals

시스템을 설계하는 것의 첫 번째 문제는 목표와 사양을 정의하는 것이다. 가장 높은 수준에서, 시스템 설계는 하드웨어 선택과 시스템 타입(기존 데스크톱/노트북, 모바일, 분산된, 또는 실시간)에 영향을 미칠 것이다.

이 가장 높은 설계 수준을 넘어서면, 요구사항은 더 지정하기 더 어려울 수 있다. 하지만, 요구사항은 사용자 목표와 시스템 목표라는 두 가지 일반적인 그룹으로 나눌 수 있다.

사용자는 시스템에서 특정한 명백한 속성을 원한다.
시스템은 사용하기 편리하고, 배우고 쓰기 쉽고, 믿을 수 있고, 안전하고, 빨라야 한다. 물론 이 사양은 시스템 설계에서 특별히 유용하지 않다. 그것을 어떻게 성취하는지 일반적인 합의가 없기 때문이다. 유사한 요구사항의 집합은 시스템을 설계, 생성, 유지, 운영 하는 개발자에 의해 정의될 수 있다. 시스템은 설계, 구현, 유지하기 쉬워야 하고, 유연하고, 믿을 수 있고, 에러가 없고, 효율적이어야 한다. 다시 말해, 이 요구사항들은 모호하고 아마 다양한 방식으로 해석될 수 있다.

간단히 말해서 운영체제의 요구사항을 정의하는 문제에 유일한 해결책은 없다. 존재하는 광범위한 시스템은 다른 요구사항이 다른 환경에서 다양한 해결책을 제공할 수 있음을 보여준다. 예를 들어, 임베디드 시스템의 실시간 운영체제인 Wind River VxWorks의 요구사항은 엔터프라이즈 어플리케이션을 위해 설계된 대규모 멀티엑세스 운영체제인 Windows Server와 상당히 달랐을 것이다.

운영체제를 지정하는 것과 설계하는 것은 매우 창의적인 작업이다. 비록 어떤 교과서도 그 방법을 알려주지 않지만, 일반적은 원리는 소프트웨어 공학 분야에서 개발되어 왔고, 이제 이 원리에 대해 논의한다.

2.7.2 Mechanisms and Policies

중요한 원칙 중 하나는 policy를 메커니즘에서 분리하는 것이다. 메커니즘은 무언가를 하는 방법을 결정하고, 정책은 무엇을 할 것인지 결정한다. 예를 들어, 타이머 구조는 CPU 보호를 보장하는 메커니즘이지만, 특정 사용자에게 타이머 설정 기간을 결정하는 것은 정책 결정이다.

정책과 매커니즘의 분리는 유연성을 위해 중요하다. 정책은 장소나 시간에 따라 바뀔 가능성이 높다. 최악의 경우, 정책에서의 각 변경은 기존 메커니즘의 변경을 요구한다. 다양한 정책에 걸쳐서 작동할만큼 유연한 일반적인 메커니즘이 바람직하다. 정책의 변경은 프로그램의 특정 매개변수만 재정의가 필요하다. 예를 들어, 특정 유형의 프로그램을 다른 프로그램보다 우선순위를 주는 메커니즘을 고려한다. 메커니즘이 정책과 적절히 분리되었다면, I/O 집약 프로그램이 CPU 집약프로그램보다 우선시되어야 하는 정책 결정을 지원하거나 반대의 정책을 지원하는데 사용될 수 있다.
마이크로커널 기반 운영체제는 기본적인 기본 빌딩 블록 세트를 구현하여 메커니즘과 정책을 분리하는 것을 극단적으로 적용한다. 이 블록은 거의 정책이 없으며, 더 고급의 메커니즘과 정책을 사용자 생성 커널 모듈 또는 사용자 프로그램 자체를 통해 추가할 수 있다. 그에 반하여, 30년 이상 사용가능한 엄청나게 인기있는 상업의 운용체제 윈도우를 고려한다. Microsoft는 메커니즘과 정책 모두 시스템에 밀접하게 인코딩하여 글로벌 모양과 느낌을 모든 윈도우 운영체제를 실행하는 디바이스에 적용하였다. 인터페이스 자체로 커널과 시스템 라이브러리에 내장되어 있기 때문에 모든 애플리케이션은 유사한 인터페이스를 가진다. Apple은 macOS와 iOS 운영 체제에서 유사한 전략을 채택했다.

우리는 상업용 및 오픈소스 운영체제 사이에 유사한 비교를 할 수 있다. 예를 들어, 윈도우와 광범위의 컴퓨팅 기기에서 실행되고 25년 이상 사용되어 온 오픈 소스 운영체제 Linux를 비교하다. "표준" Linux 커널은 특정 CPU 스케줄링 알고리즘이 있다. 이 메커니즘은 특정 정책을 지원한다. 그러나, 다른 정책을 지원하기 위해 아무나 스케줄러를 수정하거나 재배치(교체)할 수 있다

정책 결정은 모든 자원할당에 중요하다. 자원을 할당할지 말지 결정이 필요할 때마다, 정책 결정은 반드시 만들어진다. '무엇'이 아니라 '어떻게'가 문제일 때마다 반드시 결정해야 하는 메커니즘입니다.

Implementation

운영체제가 설계되면 반드시 구현되야 한다. 운영체제는 많은 사람들이 오랜 기간 작성한 많은 프로그램의 모음이기 때문에, 구현 방법에 대한 일반적인 주장을 하는 것은 어렵다.

초기 운영체제는 어셈블리어로 작성되었다. 현재 대부분은 C와 C++같은 상위 수준 언어도 작성되며, 소량의 시스템은 어셈블리어로 작성된다. 사실, 하나 이상의 상위 수준 언어가 종종 사용된다. 커널의 가장 낮은 수준은 어셈블리어과 C로 작성될 수 있다. 상위 수준 루틴은 C와 C++로 작성될 수 있으며, 시스템 라이브러리는 C++ 또는 심지어 상위 수준 언어로 작성될 수 있다. 안드로이드는 좋은 예시를 제공한다. 커널은 대부분 어셈블리어를 포함하는 C로 작성된다. 대부분의 안드로이드 시스템 라이브러리는 C또는 C++로 작성되고, 시스템에 대한 개발자 인터페이스를 제공하는 애플리케이션 프레임워크는 대부분 자바로 작성된다. 2.8.5.2.에서 안드로이드의 구조에대해 더 자세히 다룬다.

운영체제를 구현하는데에 고급 언어나 최소의 시스템 구현 언어를 사용하는 것의 장점은, 해당언어를 응용 프로그램에 사용할 때와 동일하게 얻을 수 있다. 코드를 더 빨리 작성할 수 있고, 더 치밀하고, 이해와 디버깅이 더 쉽다. 게다가, 컴파일러 기술의 개선으로 간단한 재컴파일을 통해 전체 운영체제에 생성된 코드가 개선된다. 마지막으로, 운영체제는 고급 언어로 작성됐을 경우 다른 하드웨어로 이식하기 더 쉽다. 이는 소형 임베디드 장치, Intel x64 시스템 그리고 휴대폰과 태블릿에서 실행되는 ARM 칩과 같이 여러 다른 하드웨어 시스템에서 실행되도록 의도된 운영체제에 특히 중요하다.

'고급 언어로 운영 체제를 구현하는 데 있어서 발생할 수 있는 유일한 단점은 속도가 느려지고 저장 공간 요구 사항이 증
가한다는 것입니다.
하지만 이것은 오늘날의 시스템에서는 큰 문제가 아닙니다. 전문적인 어셈블리 언어 프로그래머가 효율적인 작은 루틴을 만들
어낼 수 있지만, 대규모 프로그램의 경우 현대 컴파일러는 복잡한 분석을 수행하고 정교한 최적화를 적용하여 뛰어난 코드를 만
들어낼 수 있습니다. 현대 프로세서는 복잡한 종속성의 세부 사항을 인간의 마음보다 훨씬 더 쉽게 처리할 수 있는 심층적인
파이프라인과 여러 기능 단위를 갖추고 있습니다.
다른 시스템에서도 그렇듯이 운영 체제의 주요 성능 개선은 우수한 어셈블리 언어 코드보다 더 나은 데이터 구조와 알고
리즘의 결과일 가능성이 더 큽니다. 또한 운영 체제는 크지만 코드의 일부만이 고성능에 중요합니다. 인터럽트 핸들러, I/O 관
리자, 메모리 관리자 및 CPU 스케줄러가 아마도 가장 중요한 루틴일 것입니다. 시스템이 작성되고 올바르게 작동하면 병목
현상을 식별하고 리팩토링하여 더 효율적으로 작동할 수 있습니다'