Chapter Objectives

• OS가 제공하는 서비스들을 파악
• System calls이 OS services에 어떻게 사용되는지 설명
• monolithic, layered, microkernel, modular, hybrid 등의 OS 설계 방법들을 탐구
• OS 부팅 과정의 탐구
• OS 성능 측정을 위한 도구들의 적용
• 리눅스 커널을 이용한 kernel 모듈의 설계와 실행

2.1 Operating system services

OS는 프로그램들이 돌아갈 환경을 제공한다. 아래의 그림은 OS sevices들과 어떻게 서로 연관되어 있는지 보여준다.

OS가 사용자에게 제공하는 서비스들은 다음과 같다.

• User interface : 대부분의 OS는 User Interface(UI)를 제공한다. 여러가지 형태가 있는데, 가장 흔한것은 GUI(graphical user interface)이다. 다른 것으로는 CLI(command-line interface)가 있는데, text commands를 사용한다.

• Program execution : 시스템은 프로그램을 메모리에 로드시킨 후, 작동시켜야 한다. 프로그램은 또한 정상,비정상적으로 종료될 수 있어야 한다.

• I/O operations: 프로그램은 file이나 입출력 장치로부터 입출력을 요구할 수 있다. 효율성과 시스템 보호를 위해, 사용자는 직접적으로 입출력 장치에 접근해서는 안된다. OS가 대신 입출력 관리를 해준다.

• File-system manipulation: 프로그래머들은 디렉토리와 파일을 읽고 써야한다. 또한 삭제나 생성 역시 해야 하는데, 많은 OS들은 파일 시스템들의 다양성을 제공하여, custom하게 사용할 수 있게 해준다

• Communications : 프로세스간의 정보교환이 필요할 때가 있다. Communications은 shared memory를 이용하여 실행되며, 여러개의 process들이 shared memory에 읽고 쓰거나 message passing 방식을 통해서 정보를 주고 받는다.

• Error detection: OS는 발생 가능한 errors들을 파악하고 수정할 수 있어야 한다. 에러들은 CPU나 memory hardware, 입출력장치, user program에서 발생 가능하다. 각각의 에러들에 대해 OS는 적절한 조치를 취해서, 에러를 수정하고 일관된 연산을 가능하게 하도록 해야한다. 때때로 OS는 에러를 발생시키는 프로세스를 종료시키거나, 프로세스에게 에러 코드를 반환하여 수정하게 한다.

OS의 다른 측면으로는 system이 효율적인 연산을 가능케 한다는 점이다. Multiple process가 돌아가는 시스템들은 컴퓨터 resource를 공유함으로써, 효율성을 얻게 된다.

• Resource allocation : multi process들이 동시에 돌아갈 때, resources은 각각 할당되어야 한다. OS는 여러 종류의 resources을 관리한다. 몇 개의 resources(CPU, main memory, File system)에 관해서는 allocation code에 의해 할당된다.

• Logging : 어떤 프로그램이 얼만큼의 resources들을 사용하는지 추적해야 한다. 이러한 사용량 통계들은 시스템 관리자에게 유용한 도구가 되어, computing service를 향상하는데 도움이 될 것이다.

• Protection and security : 여러개의 프로세스들이 실행되고 있을때, 한개의 프로세스가 다른 프로세스나 OS에 간섭하는 경우는 없어야 한다. Protection(보호)는 시스템 자원들에 대한 접근이 통제되어 있다는 것을 보장한다. Security(보안)은 외부로부터의 접근을 막고, 외부 입출력 장치도 보호한다.

2.2 User and Operating-System Interface

2.2.1 Command Interpreters

많은 운영체제들은 command interpreter를 프로세스 시작이나 로그온 지점에서 돌아가는 특별한 프로그램으로 취급한다. 많은 command interpreter를 가진 시스템에서, interpreters을 shells이라 한다.

command interpreter의 목적은 다음 사용자 명령을 가져오고 실행하는 것이다. 아래와 같이 2가지 방식으로 실행된다

• command interpreter 자체에 명렁어를 실행시키는 코드를 가지고 있는 방법이다. 이 경우, 명령어마다 요구하는 코드가 있으므로, 명령어의 수가 command interpreter의 크기를 결정한다
• Unix계열에서 많이 활용되는데, 운영체제가 명령어를 시스템 프로그램들을 통해 실행시키는 방법이다. 이 방법에서는, command interpreter가 혼자 명령어를 이해하지 못하고, 명령어는 단지 메모리에 로드되어 실행되어야 할 시스템 프로그램을 identify하는 것에 사용된다.

2.2.2 Graphical User Interface

우리에게 가장 친숙한 인터페이스로, mouse-based의 window, system menu를 통해 명령어들을 실행한다.

2.3 System calls

시스템 콜(system call)은 운영 체제의 커널이 제공하는 서비스에 대해, 응용 프로그램의 요청에 따라 커널에 접근하기 위한 인터페이스이다. User mode에서 kernel mode로 바뀐후, 연산을 수행하고 결과를 User application을 제공.

2.3.1 Example

한 파일을 복사하기 위해 필요한 System calls은 위와 같이 많이 있다.

2.3.2 Application programming Interface

개발자들은 주로 API에 따라 프로그램을 설계한다. 실제로 API를 이루는 함수들은 System calls을 호출하여 application programmer에게 도움을 준다. 실제 System calls을 호출하는 것보다, API 위에서 설계하는 이유는 여러가지 이유가 있다.

먼저 Program portability이다. 즉, 같은 API 위에서는, 시스템 종류와 무관하게 프로그램이 돌아간다. 더군다나, 실제 System calls을 하는 것은 생각보다 까다롭고 어려워서, API를 사용하는 것이 효율적이기도 하다.

시스템을 다룰때 중요한 다른 요소로는, run-time-environment가 있다. system-interface는 API의 function-call을 가로채어 필수적인 system calls을 OS에게 호출한다. 이후 system call 상태를 반환한다.

2.3.3 Types of System calls

시스템 콜은 크게 위와 같이 6개의 카테고리로 분류할 수 있다.

2.4 System services

System services은 프로그램 개발과 실행을 위한 편리한 환경을 제공한다. System calls을 모아둔 간단한 것도 있으며, 복잡한 것도 존재한다. System services은 아래와 같이 분류할 수 있다. System programs을 통해 많은 운영체제들은 common problem이나 연산을 수행한다.

• File management
• Status information
• File modification
• Programming language support
• Program loading and execution
• Communications
• Background services

2.8 Operating System Structure

크고 복잡한 현대의 시스템을 다루기 위해서는 운영체제는 조심스럽게 engineered 되어야 하며, 수정하기도 쉬워야 한다.
가장 흔히 사용하는 방법으로는 task를 여러 components(modules)로 쪼개는 방법이다.

2.8.1 Monolithic Structure

OS를 구성하는 가장 간단한 방법은 구조가 없는 것, 즉 1개의 kernel에 모든 기능을 넣는 것이다. 이러한 구조를 monolithic structure이라 하며, OOS 설계에서 가장 흔히 사용되는 기법이다. 하지만 monolithic structure는 확장하기 어렵다는 단점이 있다. 그러나 system-call interfaces에서 적은 overhead와 빠른 communication에 의해, speed와 efficiency가 매우 좋다는 장점이 있다.

위 그림처럼 모든 기능이 system-call 인터페이스과 하드웨어 사이 커널에 있을 수 있다.

2.8.2 Layered Approach

monolithic approach는 tighly coupled한 시스템이라고도 하는데, 이는 시스템의 한 부분의 변화가 다른 부분도 영향을 끼칠 수 있기 때문이다.

이와 반대로, 우리는 loosly coupled한 시스템을 설계할 수도 있다. 즉, 시스템을 특정 기능을 갖는 여러 부분요소로 쪼개는 것이다. 이러한 방법의 장점으로는, 한 부분의 변화가 그 부분만 영향을 끼친다는 점이다. 이로 인해 시스템 내부에 변화와 생성을 자유롭게 할 수 있다.

대표적인 방법이 Layered approach이다. OS를 여러 계층으로 나누는 방법이다. 바닥 층은 HW, 최고층은 user interface로 되어있다. 이 방법의 장점으로는 construction과 debugging이다. 각 층은 lower-level layers의 operations을 사용한다. 또한 lower level의 layers은 이미 debug된 상태이기 때문에, 만약 에러가 발생해도, 그 계층만 살펴 debugging을 하면 되므로 효율적이다. 이 접근법은 특히 컴퓨터 네트워크 분야서 성공을 거두었다.

2.8.3 Microkernels

MACH이라는 운영체제에서 처음으로 사용된 microkernel approach. 이 방법은 OS의 불필요한 요소들을 커널에서 제거하고, user-level 단계의 프로그램들로 별도의 공간을 두어서 분리시키는 것이다. 이로 인해 small kernel이 된다.

마이크로커널의 주 기능은 client program과 다양한 services간의 communication을 제공하는 것이다. 둘이 직접적인 통신을 할 수 없기에, 마이크로커널을 통해 messages를 주고 받는 방식으로 소통한다.

이 방법의 장점으로는 OS를 확장/수정하기 쉽다는 것이다. services들을 커널이 아닌 user space에서 수정하면 되기 때문이다. 또한 분리되어 있어서 security, reliability가 좋다.

2.8.4 Modules

최근에 가장 좋은 OS 설계로 알려진 것은 loadable kernel modules (LKMs)이다. 이 방법에서는 커널에 핵심 요소들이 있고, 부가 서비스들을 modules을 통해 추가할 수 있다. Linux, macOS, Windows에 적용되는 방식이다. 핵심 기능이 있는 커널이 돌아가면서 다른 서비스들을 동적으로 실행할 수 있다는 것이다. 전반적으로 각 커널 section마다 정의되어 있다는 점에서 layered system을 닮았지만, primary module이 코어 기능을 가지고 있으며 다른 모듈을 부른다는 점에서는 microkernel을 닮기도 했다.

이 방법의 장점으로는 새로운 services을 추가하는 것이 쉬우며(직접 커널에 연결), message passing 같은 것이 필요하지 않아 빠른 속도가 있다.

2.8.5 Hybrid Systems

많은 운영체제들은 위에서 언급되었던 설계 기법들을 혼합하여 사용한다. 리눅스는 하나의 공간에 OS가 있기 때문에 monolithic하다고 할수도 있지만, 새로운 기능을 dynamically하게 추가할 수 있다는 점에서 modular하다고 할수도 있다. 윈도우 역시 큰 관점에서는 monolithic하지만, microkernel 같이 subsystems로 구성되기도 한다.