Notice
Recent Posts
Recent Comments
05-21 07:17
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Archives
Today
Total
관리 메뉴

Byeol Lo

2.7 Operating-System Design and Implementation 본문

OS/OS Design

2.7 Operating-System Design and Implementation

알 수 없는 사용자 2024. 4. 9. 02:05

 운영체제를 설계하고 구현하는 데 있어서 마주치는 문제들을 보자.

 

2.7.1 Design Goals

 시스템을 설계하는 첫번째 문제는 '목표' 와 '사양' 을 정의하는 것이다. 원래 높은 계층에서 시스템 디자인은 하드웨어와 시스템 유형에 대해 영향을 받을 것이다. 여기서 시스템 유형은 데스크톱/랩톱, 모바일, 분산, 실시간 시스템 등을 말한다. 그리고 높은 수준의 설계에서는 요구사항을 구체화하기가 더 많이 힘들어질 수 있지만, 이러한 요구사항들은 두 기본적인 그룹으로 나뉘어지며, User GoalsSystem Goals이 있다.

 사용자들은 시스템에서 특정한 명백한 속성을 원한다. 시스템은 사용하기 편리하고, 배우기와 사용하기가 쉽고, 신뢰할 수 있고, 안전하며 빠를 필요가 있다. 이러한 명세는 시스템 설계에 있어서 유용하지 않다. 왜냐하면 이러한 속성을 어떻게 달성해야 하는지에 대한 일반적인 합의가 없기 때문이다. 시스템을 디자인하고, 구현하고, 유지보수하고, 운영해야 하는 개발자들도 비슷한 요구사항을 정의할 수 있다. 시스템은 설계하기 쉽고, 구현하기 쉽고, 유지보수하기 쉽고, 유연하고, 신뢰할 수 있으며, 오류가 없고 효율적이어야 한다. 이러한 요구사항은 매우 모호하고 여러가지 방법으로 해석될 수 있는 것이다.

 따라서, 운영체제의 요구사항을 정의하는 문제에 대한 기가 막힌 해결책이 없다. 존재하는 다양한 시스템 범위는 서로 다른 요구사항이 다양한 환경에 대한 다양한 해결책으로 이어질 수 있음을 보여준다. 따라서 환경(사양), 목표에 맞는 다양한 시스템을 이용하여 해결책을 구사해야 한다는 것이다. 운영체제를 명시하고 디자인하는 것은 매우 창의적인 작업이다.. 비록 교과서에서 그 방법을 알려주진 않지만, 소프트웨어 공학 분야에서 일반적인 원칙이 개발되어 있고, 이러한 원칙 중 일부에 대한 것을 여기서 보도록 한다.

 

2.7.2 Mechanisms and Policies

 중요한 원칙 중 하나는 정책과 메커니즘의 분리이다. Mechanism이란 '어떻게 해야하는지'를 결정하고, Policy이란 '무엇을 할 것인지'를 결정한다. 정책과 메커니즘의 분리는 유연성을 위해 중요하다. 정책은 장소나 시간을 통해 변경될 가능성이 높고, 최악의 경우에는 정책 변경마다 기본 메커니즘 변경이 필요할 수 있다. 이러한 정책을 지원하기에 충분히 유연한 메커니즘이 올바른 구현인 것이다. 이렇게 구현한다면 정책 변경이 시스템의 일부 파라미터만 재정의하도록 요구할 수 있도록 충분히 유연하게 된다는 것이다.

 예를 들어, 특정 유형의 프로그램에 우선 순위를 부여하는 메커니즘을 고려해보자. 메커니즘이 정책과 적절하게 분리되어 있다면, I/O-intensive 프로그램이 CPU-intensive 프로그램 보다 우선 순위를 가지도록 지원하는 정책 결정을 피거나 아니면 그 반대의 정책 또한 지원할 수 있도록 유연하게 된다는 것이다.

 마이크로 커널 기반 운영체제는 basic set of primitive building blocks을 구현하여 메커니즘과 정책의 분리를 심도있게 적용한다. 이 블록들은 거의 정책이 없어서 사용자가 커널 모듈이나 사용자 프로그램을 통해 고급 메커니즘과 정책을 추가할 수 있다. 이와는 반대로 30년 이상 사용 가능한 인기가 많은 운영체제인 Windows를 보자 Microsoft은 Windows 운영 체제를 실행하는 모든 기기에서 일관된 외관과 느낌을 유지하기 위해 시스템에 메커니즘과 정책을 밀접하게 통합했다. 모든 응용 프로그램은 인터페이스 자체가 커널과 시스템 라이브러리로 만들어 졌기 때문에 유사한 인터페이스를 갖는다.

 Linux는 '표준' Linux 커널에는 특정 CPU 스케줄링 알고리즘이 있다. 이 알고리즘은 특정 정책을 지원하는 메커니즘이지만, 누구든지 스케줄러를 수정하거나 교체하여 다른 정책을 지원할 수 있다는게 큰 장점이다. 정책 결정은 모든 자원 할당에 중요하고, 자원을 할당할 지 여부를 결정해야 할 때마다 정책 결정이 이루어져야 한다. '어떻게'가 '무엇'보다 중요한 경우, 결정해야 하는 것은 메커니즘이다.

 

2.7.3 Implementation

 한 번 운영 체제가 설계되면, 이를 구현해야 한다. 운영체제는 오랜 기간 동안 많은 사람들이 작성한 많은 프로그램의 집합이기 때문에 어떻게 구현되는지에 대한 일반적으로 진술하기가 매우 어렵다.

 초기 운영체제는 어셈블리 언어로 작성되었다. 하지만 대부분의 운영체제는 C나 C++와 같은 고급언어로 작성되고, 일부 시스템은 어셈블리 언어로 작성된다. 실제로 하나 이상의 고급 언어를 사용하는 경우가 많다. 커널의 가장 낮은 수준은 어셈블리 언어와 C로 작성될 수 있으며, 더 높은 수준의 루틴은 C와 C++로 작성 될 수 있다. 한 가지 예로 안드로이드는 그 커널의 대부분이 C로 작성되었으며 일부 어셈블리 언어로 작성되어 있다. 대부분의 안드로이드 시스템 라이브러리는 C나 C++로 작성되었고, 시스템에 대한 개발자의 인터페이스를 제공하는 응용 프로그램 프레임워크는 대부분 자바로 작성되었다.

 고급 수준의 언어나 적어도 시스템 구현 언어를 운영 체제를 구현할 때 사용하는 장점은 응용 프로그램에서 해당 언어를 사용할 때 얻는 이점과 동일하다. 이때 코드를 더 빨리 작성할 수 있고, 더 간결하고, 제 3자가 봤을 때 이해하기 쉽고 디버그 하기가 쉽기 때문이다. 게다가 컴파일러 기술의 향상으로 인해 단순한 재컴파일로 전체 운영 체제의 생성된 코드가 효율적이게 된다. 마지막으로 고급 수준의 언어로 작성된 운영체제는 다른 하드웨어로의 이식이 훨씬 쉽다. 특히 여러가지 다른 하드웨어 시스템에서 실행되도록 의도한 바라면 이 운영체제는 고급 수준의 언어로 작성하는 것에 관심을 두어야 한다. 이는 작은 임베디드 장치, 인텔 x86 시스템, 폰, 태블릿 에서 실행되는 ARM 칩과 같은 여러 가지 다른 하드웨어 시스템에서 실행되도록 의도된 운영 체제에 특히 중요하다.

 고급 수준의 언어로 운영체제를 구현하는 유일한 단점은 속도 감소늘어난 용량이다. 하지만, 이는 시스템에서 주요 문제가 아니다. 숙련된 어셈블리어 프로그래머는 효율적인 작은 루틴을 생성할 수 있지만, 이 프로그래머가 대형 프로그램의 경우에는 부분적인 것만으로는 힘들며, 이는 현대 컴파일러가 더 나은 최적화 기법을 제공하기 때문에, 더 나은 코드를 생성할 수 있다는 것이다. 그래서 복잡한 분석을 수행하고 우수한 코드를 생성하는 정교한 최적화를 적용할 수 있기 때문에 큰 규모에는 현대의 컴파일러의 최적화 기술을 적용하고, 작은 규모에서는 어셈블리어를 사용하는게 효과적이다. 이러한 대규모는 현대 프로세서의 깊은 파이프라인과 다중 기능 장치에 적용하여 인간의 머리로 처리하기 어려운 복잡한 종속성의 세부 사항들을 처리할 수 있다.

 다른 시스템에서와 마찬가지로, 운영 체제의 주요 성능 향상은 우수한 어셈블리어 코드보다는 더 나은 데이터 구조 및 알고리즘의 결과일 가능성이 더 크다. 게다가 운영 체제의 크기는 크지만, 실제로 높은 성능을 제공하는 데 중요한 부분은 그리 많지 않다. 인터럽트 처리기, I/O 관리자, 메모리 관리자 및 CPU 스케줄러가 여기서 가장 중요한 루틴이다. 시스템이 올바르게 작성되고 제대로 작동하는지 보고, 그 다음 병목 현상을 식별하고 효율적으로 작동하도록 재구성할 수 있다.

'OS > OS Design' 카테고리의 다른 글

3.1 Process Concept  (0) 2024.04.09
2.8 Operating-System Structure  (0) 2024.04.09
2.6 Why Applications are Operating-System Specific  (0) 2024.04.09
2.5 Linkers and Loaders  (0) 2024.04.08
2.4 System Services  (0) 2024.04.08
Comments