[Operating System Concepts 10th] 2. Operating System Structures 리뷰

본 글은 Operating System Concepts 10th (운영체제) 책을 보며 내용을 개인 공부에 목적으로 정리했습니다.
이전에 운영체제 관련 강의들을 들으면서 정리한 시리즈 글들이 있는데,
지식을 습득하는 데 있어 가장 느리지만 가장 빠른 방법이 원본책을 자세히 보는 것이라 생각됩니다.
책 내용들을 최대한 이해하기 위해 거의 모든 내용을 담고 있습니다.

책 pdf 링크 : Operating System Concepts 10th Edition by Abraham Silberschatz Peter B Galvin Greg Gagne pdf free download
연습 문제 정답지 : Solutions of Practice Exercises, Tenth Edition of Operating System Concepts, AVI SILBERSCHATZ

2. Operating System Structures

• 운영체제를 살펴보기 위한 3가지 유리한 관점이 있다.

1. 운영체제가 제공하는 서비스에 초점을 맞추는 것이다.
2. 운영체제가 사용자와 프로그래머에게 제공하는 인터페이스에 초점을 맞추는 것이다.
3. 시스템의 구성요소와 그들의 상호 연결에 초점을 맞추는 것이다.

• 목표
  1. 운영체제에서 제공하는 서비스를 식별한다.
  2. 운영체제 서비스를 제공하기 위해 시스템 콜을 사용하는 방법을 설명한다.
  3. 운영체제 설계를 위한 모놀리식, 계층화, 마이크로 커널, 모듈 및 하이브리드 전략을 비교 및 대조한다.
  4. 운영체제 부팅 프로세스를 설명한다.
  5. 운영체제 성능을 모니터링하기 위한 도구를 적용한다.
  6. Linux 커널과 상호 작용하기 위한 커널 모듈을 설계하고 구현한다.

2.1 Operating-System Services

• 운영체제는 프로그램 실행 환경을 제공한다.
• 운영체제는 프로그램과 그 프로그램의 사용자에게 특정 서비스를 제공한다.
• 서비스(service)는 프로그래머가 프로그래밍 작업을 더 쉽게 수행할 수 있도록 한다.
• 사용자 인터페이스(user interface)
  • 거의 모든 운영체제는 사용자 인터페이스(UI)를 제공한다.
  • 가장 일반적으로 그래픽 사용자 인터페이스(graphical user interface, GUI)가 사용된다.
  • 휴대전화 및 태블릿과 같은 모바일 시스템은 터치 스크린(touch screen) 인터페이스를 제공하여 사용자가 손가락으로 화면 버튼을 눌러 선택 항목을 선택할 수 있다.
  • 명령어 라인 인터페이스(command-line interface, CLI)는 명령을 사용하며 이를 입력할 방법이 사용된다.
• 프로그램 실행(program execution)
  • 시스템은 프로그램을 메모리에 적재해 실행할 수 있어야 한다.
  • 프로그램은 정상이든 아닌 실행을 끝낼 수 있어야 한다.
• 입출력 연산(I/O operation)
  • 실행 중인 프로그램은 입출력을 요구할 수 있다.
  • 이러한 입출력에는 파일 혹은, 입출력 장치가 연관될 수 있다.
• 파일 시스템 조작(file system manipulation)
  • 프로그램은 파일을 읽고 쓸 필요가 있다.
• 통신(communication)
  • 통신은 공유 메모리(shared memory)를 통해서 구현될 수도 있고, 메시지 전달(message passing) 기법을 사용하여 구현될 수 있다.
  • 메시지 전달은 정보의 패킷(packet)들이 운영체제에 의해 프로세스들 사이를 이동한다.
    • 패킷(packet) : 네트워크를 통해 전송하기 쉽도록 자른 데이터의 전송 단위 ¹
• 오류 탐지(error detection)
  • 운영체제는 모든 가능한 오류를 항상 의식하고 있어야 한다.
  • 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 유형의 오류에 대해 적당한 조치를 취해야 한다.

• 시스템 자체의 효율적인 동작을 보장하기 위한 운영체제 기능들도 존재한다.
• 다수의 프로세스가 사용하는 시스템에서는 프로세스들 간에 컴퓨터 리소스를 공유하게 함으로써 효율성을 얻을 수 있다.
• 리소스 할당(resource allocation)
  • 다수의 프로세스나 다수의 작업이 동시에 실행될 때, 그들 각각에 리소스를 할당해 주어야 한다.
  • 운영체제는 여러 가지 다른 종류의 리소스를 관리한다.
• 기록 작성(logging)
  • 우리는 어떤 프로그램이 어떤 종류의 컴퓨터 리소스를 얼마나 많이 사용하는지를 추적할 수 있길 원한다.
  • 로그 관리는 회계 또는 단순히 사용 통계를 내기 위해 사용된다.
• 보호(protection)와 보안(security)
  • multi-user 컴퓨터 시스템 또는 네트워크로 연결된 컴퓨터 시스템에 저장된 정보의 소유자(owner)는 그 정보의 사용을 통제하길 원한다.
  • 서로 다른 여러 프로세스가 동시(concurrently)하게 수행될 때, 한 프로세스가 다른 프로세스나 운영체제 자체를 방해해서는 안 된다.
  • 보호는 시스템 자원에 대한 모든 접근이 통제되도록 보장하는 것을 필요로 한다.
  • 보안은 각 사용자가 리소스에 대한 접근을 원할 때 패스워드를 사용해서 시스템에게 자기 자신을 인증하는 것으로부터 시작된다.

2.2 User and Operating-System Interface

2.2.1 Command-Interpreter

• 명령어 라인 인터페이스는 사용자가 운영체제가 수행할 명령어를 직접 입력할 수 있도록 한다.
• 이 수준에서 제공된 많은 명령은 파일을 조작한다.(생성, 삭제, 리스트, 프린트, 복사, 수행 등)
• 명령어들은 두 가지 일반적인 방식으로 구현될 수 있다.
  1. 명령 인터프리터 자체가 명령을 실행할 코드를 가지는 경우이다.
  2. 시스템 프로그램에 의해 대부분의 명령을 구현하는 것이다.
     • 이러한 경우 명령 인터프리터는 전혀 그 명령을 알지 못하고, 단지 메모리에 적재되어 실행될 파일을 식별하기 위해 명령을 사용한다.
     • ex. rm file.txt

2.2.2 Graphical User Interface

• GUI는 데스크톱(desktop)이라고 특정지어지는 마우스를 기반으로 하는 윈도우 메뉴 시스템을 사용한다.
• 사용자는 마우스를 움직여 마우스 포인터를 프로그램, 파일, 시스템 기능 등을 나타내는 화면상의 이미지(icon)에 위치시킨다.
• 마우스 포인터의 위치에 따라, 마우스 버튼을 누름으로써 프로그램을 호출하거나 파일 혹은 디렉토리를 선택할 수도 있고, 명령을 포함한 메뉴를 잡아당길 수도 있다.

2.2.3 Touch-Screen Interface

• 스마트폰 및 태블릿 컴퓨터는 일반적으로 터치스크린 인터페이스를 사용한다.
• 사용자는 터치스크린에서 손가락을 누르거나 스와이프(swip)하는 등의 제스처(gesture)를 취하여 상호 작용한다.

2.3 System Calls

• 시스템 콜(system call)은 운영체제에 의해 사용 가능하게 된 서비스에 대한 인터페이스를 제공한다.
• 특정 저수준(low-level) 작업은 어셈블리 명령을 사용하여 작성되어야 하더라도 이러한 호출은 일반적으로 C와 C++언어로 작성된 함수 형태로 제공된다.
  • 저수준(low-level) 작업은 예를 들어 하드웨어를 직접 접근해야 하는 작업
  • 어셈블리(assembly) : 기계 명령어를 좀더 이해하기 쉬운 기호 코드로 나타낸 것

2.3.1 Example

• 각각의 연산들은 많은 다른 시스템 콜을 필요로 한다.

2.3.2 Application Programming Interface

• 간단한 프로그램이라도 운영체제의 기능을 아주 많이 사용하게 된다.
  • 종종 초당 수천 개의 시스템 콜을 수행하게 된다.
• 사용자 대부분은, 이런 상세한 내용을 결코 알지 못한다.
• 대부분의 애플리케이션 개발자들은 애플리케이션 프로그래밍 인터페이스(application programming interface, API)에 따라 프로그램을 설계한다.

  • API는 각 함수에 전달되어야 할 파라미터들과 프로그래머가 기대할 수 있는 반환 값을 포함하여 애플리케이션 개발자가 사용 가능한 함수의 집합을 명시한다.

    
    이미지출처 ²

  • 쉽게 말해 API는 프로그램들이 서로 상호작용하는 것을 도와주는 매개체이다. ²

• 프로그래머는 운영체제가 제공하는 코드의 라이브러리를 통하여 API를 활용한다.
• 모든 운영체제는 고유의 시스템 콜 이름을 가진다.
• API에 따라 프로그래밍을 하는 것을 선호하는 이유가 있다.
  1. 프로그램의 호환성과 관련이 있는데, API에 따라 프로그램을 설계하는 응용 프로그래머는 자신의 프로그램이 같은 API를 지원하는 어느 시스템에서건 컴파일되고 실행된다는 것을 기대할 수 있다.
  2. 시스템 콜은 좀 더 자세한 명세가 필요하고 프로그램상에서 작업하기가 API보다 더 어렵다.

• 시스템 콜을 처리하는 데 있어 중요한 또 다른 요소는 실행시간 환경(run-time environment)이다.
  • 실행시간 환경(run-time environment, RTE) : 특정 프로그래밍 언어로 작성된 애플리케이션을 실행하는 데 필요한 전체 소프트웨어 제품군
• RTE는 운영체제가 제공하는 시스템 콜에 대한 연결고리 역할을 하는 시스템 콜 인터페이스(system call interface)를 제공한다.
• 시스템 콜 인터페이스는 API 함수의 호출을 가로채어 필요한 운영체제 시스템 콜을 부른다.
• 각 시스템 콜에는 번호가 할당되고 시스템 콜 인터페이스는 이 번호에 따라 인덱스되는 테이블을 유지한다.
• 시스템 콜 인터페이스는 의도하는 시스템 콜을 부르고 시스템 콜의 상태와 반환 값을 돌려준다.

• 운영체제 인터페이스에 대한 대부분의 자세한 내용은 API에 의해 프로그래머로부터 숨겨지고 RTE에 의해 관리된다.

• 운영체제에 파라미터를 전달하기 위해서 가장 간단한 방법으로 파라미터를 레지스터 내에 전달한다.
• 그러나 어떤 경우는 레지스터보다 더 많은 파라미터가 있을 수 있다.
• 이러한 경우에 파라미터는 메모리 내의 블록이나 테이블에 저장되고, 블록의 주소가 레지스터 내에 파라미터로 전달된다.

2.3.3 Types of System Calls

• 시스템 콜은 다음과 같은 5가지 중요한 범주로 묶을 수 있다.
  • 프로세스 제어(process control)
  • 파일 관리(file management)
  • 장치 관리(device management)
  • 정보 유지 보수(information maintenance)
  • 통신(communication)
  • 보호(protection)

2.3.3.1 Process Control

• 정상이거나 비정상인 상황에서, 운영체제는 명령 인터프리터로 제어(control)를 전달해야 한다.
• 명령 인터프리터는 이어 다음 명령을 읽는다.

• 빈번하게, 2개 이상의 프로세스들은 데이터를 공유한다.
• 공유되는 데이터의 무결성(integrity)을 보장하기 위해, 운영체제는 프로세스가 공유 데이터를 락(lock)을 할 수 있는 시스템 콜을 제공한다.
  • 락(lock) : 공유 자원을 하나의 스레드가 사용하고 있을 때 다른 스레드가 공유 자원을 사용하지 못 하도록 제한을 거는 것이다. ³
• 그러면 락이 해제될 때까지 어느 프로세스도 데이터에 접근할 수 없게 된다.

• 프로세스 제어는 너무 많은 측면과 다양성이 있어 단일 태스킹 시스템과 멀티 태스킹 시스템의 두 예를 들 것이다.

• Arduino는 마이크로 컨트롤러와 다양한 이벤트에 반응하는 입력 센서로 구성된 간단한 하드웨어 플랫폼이다.
• Arduino 플랫폼은 운영체제를 제공하지 않는 대신 부트 로더(boot loader)로 불리는 작은 소프트웨어가 스케치(sketch)를 Arduino 메모리의 특정 영역으로 적재한다.
  • 스케치(sketch) : 컴파일된 프로그램
• 스케치가 적재되면 실행되기 시작하고 반응하도록 프로그램된 이벤트를 기다린다.

• FreeBSD는 멀티 태스킹 시스템의 예이다.
• 사용자가 시스템에 로그인할 때 사용자가 선택한 셸이 수행되어 명령을 기다렸다가 사용자가 요청한 프로그램을 수행한다.
• FreeBSD는 멀티 태스킹 시스템이기 때문에 명령 인터프리터는 다른 프로그램이 실행되는 동안 수행을 계속할 수 있다.

2.3.3.2 File Management

• 파일을 다루는 몇 가지 공통적인 시스템 콜을 알아본다.
• 우선 파일을 생성(create())하고 삭제(delete())할 수 있어야 한다.
• 파일이 생성되면 그것을 열고(open()) 사용해야 한다.
• 또한 읽고(read()), 쓰고(write()), 그리고 위치 변경(reposition())할 수 있다.
• 파일을 더 이상 사용하지 않음을 나타내는 파일 닫기(close())가 필요하다.

2.3.3.3 Device Management

• 프로세스는 작업을 계속 수행하기 위해 추가 자원이 필요할 수 있다.
  • 이러한 추가 자원은 메인 메모리, 디스크 드라이브, 파일 접근 등이 될 수 있다.
• 만약 리소스들을 사용할 수 있다면, 이들 리소스가 주어지고, 제어가 사용자 프로그램으로 복귀될 수 있다.
• 그렇지 않다면, 프로그램은 충분한 리소스가 사용 가능하게 될 때까지 기다려야 한다.

2.3.3.4 Information Maintenance

• 많은 시스템 콜은 단순히 사용자 프로그램과 운영체제 간의 정보 전달을 위해 존재한다.
• 또한 다른 시스템 콜 집합은 프로그램 디버깅에 도움이 된다.
• 많은 운영체제는 프로그램의 시간 프로파일(time profile)을 제공한다.
  • 시간 프로파일(time profile) : 그 프로그램이 특정 위치, 혹은 위치의 집합에서 수행한 시간의 양을 나타낸다.
• 운영체제는 현재 운영되고 있는 모든 프로세스에 관한 정보를 가지고 있으며, 이러한 정보에 접근하기 위한 시스템 콜이 있다.

2.3.3.5 Communication

• 통신 모델에는 메시지 전달(message passing)과 공유 메모리(shared memory) 2가지 일반적인 모델이 있다.
• 메시지 전달(message passing)에서는 통신하는 두 프로세스가 정보를 교환하기 위하여 서로 메시지를 주고받는다.
  • 메시지(message)는 두 프로세스 사이에 직접 교환되거나 메일박스(mailbox)를 통하여 간접적으로 교환될 수 있다.
• 통신이 이루어지기 전에 연결이 반드시 열려야 한다.
• 그리고 상대 통신자의 이름을 반드시 알고 있어야 한다.
  • 네트워크의 각 컴퓨터는 호스트 이름(host name)을 가지며, 각 컴퓨터는 이들 이름으로 일반적으로 알려져 있다.
  • 또한, 각 프로세스는 프로세스 이름(process name)을 가지고 있으며, 이 이름은 운영체제에 의해 동등한 식별자(identifier)로 변환되고, 이 식별자는 운영체제가 그 프로세스를 가리키는 데 사용할 수 있다.
• 연결을 받아들일 프로세스들의 대부분은 특수 목적의 데몬(daemon)으로서, 그들은 연결을 위해 대기 호출을 수행하고 연결이 이루어질 때 깨어난다.
  • 데몬(daemon) : 사용자가 직접 제어하지 않고, 백그라운드에서 돌면서 여러 작업을 하는 프로그램 ⁴

• 공유 메모리 모델에서 프로세스는 다른 프로세스가 소유한 메모리 영역에 대한 접근을 위해 shared_memory_create()와 shared_memory_attach() 시스템 콜을 사용한다.
• 보통 운영체제는 락이 있는데, 공유 메모리는 두 개 이상의 프로세스가 이러한 제한을 제거하는데 동의할 것을 필요로 한다.
• 그런 후, 이들 프로세스는 이러한 공유 영역에서 데이터를 읽고 씀으로써 정보를 교환할 수 있다.
• 프로세스는 동일한 위치에 동시에 쓰지 않도록 보장할 책임을 진다.

2.3.3.6 Protection

• 보호는 컴퓨터 시스템이 제공하는 자원에 대한 접근을 제어하기 위한 기법을 지원한다.

2.4 System Services

• 시스템 서비스(system service)는 시스템 유틸리티(system utility)로도 알려진, 프로그램 개발과 실행을 위해 더 편리한 환경을 제공한다.

• 파일 관리(file management)
  • 이들 프로그램은 파일과 디렉토리를 create, delete, copy, rename, print, list, access한다.
• 상태 정보(status information)
  • 프로그램은 시스템에게 날짜, 시간, 사용 가능한 메모리와 디스크 공간의 양, 사용자 수, 혹은 이와 비슷한 상태 정보를 묻거나 상세한 성능, 로깅 및 디버깅 정보를 제공한다.
• 파일 변경(file modification)
  • 디스크나 다른 저장 장치에 저장된 파일의 내용을 생성하고 변경하기 위해 다수의 문장 편집기를 사용할 수 있다.
• 프로그래밍 언어지원(programming-language support)
  • 일반적인 프로그래밍 언어들에 대한 컴파일러, 어셈블러, 디버거 및 해석기가 종종 운영체제와 함께 사용자에게 제공되거나 별도로 다운로드 받을 수 있다.
• 프로그램 적재와 수행(program loading and execution)
  • 일단 프로그램이 어셈블되거나 컴파일된 후, 그것이 수행되려면 반드시 메모리에 적재되어야 한다.
  • 시스템은 절대 로더(absolute loader), 재배치 가능 로더(relocatable loader), 링키지 에디터(linkage editor)와 중첩 로더(overlay loader) 등을 제공할 수 있다.
• 통신(communication)
  • 이들 프로그램은 프로세스, 사용자, 그리고 다른 컴퓨터 시스템들 사이에 가상 접속을 이루기 위한 기법을 제공한다.
• 백그라운드 서비스(background services)
  • 일부는 시스템이 정지될 때까지 계속해서 실행되는 프로세스가 존재한다.

2.5 Linkers and Loaders

• 일반적으로 프로그램은 디스크에 이진 실행 파일(.exe)로 존재한다.
• CPU에서 실행하려면 프로그램을 메모리와 가져와 프로세스 형태로 배치되어야 한다.

• 소스 파일(source file)은 임의의 물리 메모리 위치에 적재되도록 설계된 오브젝트 파일(object file)로 컴파일(compile)된다.
  • 이러한 형식을 재배치 가능 오브젝트 파일(relocatable object file)이라고 한다.
• 다음으로 링커(linker)는 이러한 재배치 가능 오브젝트 파일을 하나의 이진 실행(executable) 파일로 결합한다.
• 로더(loader)는 이진 실행 파일을 메모리에 적재하는 데 사용되며, CPU 코어에서 실행할 수 있는 상태가 된다.
• 링킹(linking) 및 로딩(loading)과 관련된 활동은 재배치(relocation)로, 프로그램 부분에 최종 주소를 할당하고 프로그램 코드와 데이터를 해당 주소와 일치하도록 조정하여 프로그램이 실행될 때 코드가 라이브러리 함수를 호출하고 변수에 접근할 수 있게 한다.
• 위 Figure 2.11에서 로더를 실행하려면 명령어 라인에 실행 파일의 이름을 입력하기만 하면 된다는 것을 알 수 있다.
• UNIX 시스템의 명령어 라인에 프로그램 이름을 입력하면 shell은 먼저 fork() 시스템 콜을 사용하여 프로그램을 실행하기 위한 새 프로세스를 생성한다.
• 그런 다음 shell은 exec() 시스템 콜로 로더를 호출하고 exec()에 실행 파일 이름을 전달한다.
• 그런 다음 로더는 새로 생성된 프로세스의 주소 공간을 사용하여 지정된 프로그램을 메모리에 적재한다.

• 실제로 시스템 대부분에서는 프로그램이 적재될 때 라이브러리를 동적으로 링크할 수 있게 된다.
• 예를 들어, Windows는 동적 링킹 라이브러리(dynamically linked library, DLL)를 지원한다.
  • 라이브러리(library) : 소프트웨어 개발에서 자주 쓰고 기초적인 함수들을 중복 개발하는 것을 피하기 위해 표준화된 함수 및 데이터 타입을 미리 만들어서 모아 놓은 것 ⁵
  • 동적 링킹 라이브러리(dynamically linked library, DLL) : 실행 파일에서 해당 라이브러리의 기능을 사용 시에만, 라이브러리 파일을 참조하여 기능을 호출한다. ⁵
    • 컴파일 시점에 실행 파일에 함수를 복사하지 않고, 함수의 위치정보만 갖고 그 함수를 호출할 수 있게 한다.
• 이 방법의 장점은 실행 파일에서 사용되지 않을 수 있는 라이브러리를 링크하고 로드하지 않아도 된다는 것이다.
  • 대신, 라이브러리는 조건부로 링크되며 프로그램 실행 시간에 필요한 경우 적재된다.
• 여러 프로세스가 동적으로 링크된 라이브러리를 공유할 수 있어, 메모리 사용이 크게 절약될 수 있다.

• 오브젝트 파일 및 실행 파일은 일반적으로 표준화된 형식을 가진다.
  • 이 표준 형식은 컴파일된 기계 코드 및 프로그램에서 참조되는 함수 및 변수에 대한 메타데이터를 포함하는 기호 테이블을 포함한다.
• UNIX 및 Linux 시스템의 경우 이 표준 형식을 ELF(Executable and Linkable Format)라고 한다.

2.6 Why Applications Are Operating-System Specific

• 각 운영체제는 고유한 시스템 콜 집합을 제공한다.
  • 시스템 콜(system call)은 응용 프로그램이 사용할 수 있도록 운영체제가 제공하는 서비스 집합의 일부이다.
• 다음 3가지 방법으로 응용 프로그램이 여러 운영체제에서 실행될 수 있게 만들어 준다.

1. 응용 프로그램은 운영체제마다 인터프리터가 제공되는 인터프리터 언어로 작성될 수 있다.
   • 인터프리터(interpreter)는 소스 프로그램의 각 라인을 읽고, 상응하는 기계어 명령을 실행하고, 해당 운영체제의 시스템 콜을 호출한다.
2. 응용 프로그램은 실행 중인 응용 프로그램을 포함하고 있는 가상 머신을 가진 언어로 작성될 수 있다.
3. 응용 프로그램 개발자는 컴파일러가 기기 및 운영체제 고유의 이진 파일을 생성하는 표준 언어 또는 API를 사용할 수 있다.

2.7 Operating-System Design and Implementation

2.7.1 Design Goals

• 시스템을 설계하는 데에 첫번째 문제점은 시스템의 목표와 명세를 정의하는 일이다.
• 요구 조건은 근본적으로 사용자 목적과 시스템 목적으로 나눌 수 있다.
  • 사용자들이 보았을 때 시스템은 사용하기 쉽고 편리하며, 배우기 쉽고, 믿을 수 있고, 안전하고, 신속해야 한다.
  • 시스템 목적으로 보았을 때, 운영체제는 설계, 구현, 유지 보수가 쉬어야 하며, 도한 적응성, 신뢰성, 무오류, 효율성을 가져야 한다.

2.7.2 Mechanisms and Policies

• 한 가지 중요한 원칙은 기법(mechanism)으로부터 정책(policy)를 분리하는 것이다.
• 기법은 어떤 일을 어떻게(how) 할 것인가를 결정하는 것이고, 정책은 무엇(what)을 할 것인가를 결정하는 것이다.

2.7.3 Implementation

• 운영체제를 구현하기 위해 고급 언어나 최소한 시스템 구현 언어를 사용함으로써 얻는 장단점이 있다.
• Pros
  • 그 언어가 응용 프로그램을 위해 사용될 때 생기는 장점과 같다.
    • 코드 빨리 작성 가능하다.
    • 더욱 간결하다.
    • 이해하기 쉽고, 디버그하기도 쉽다.
  • 다른 하드웨어로 이식하는 것이 쉽다.
• Cons
  • 속도가 느리고 저장 장치가 많이 소요되는 것이다.
• 사실 운영체제의 주요 성능 향상은 우수한 어셈블리어 코드보다는 좋은 자료구조와 알고리즘의 결과일 가능성이 크다.

2.8 Operating-System Structures

• 구성요소들이 어떤 방법으로 상호 연결되고 하나의 커널로 결합되는지를 알아본다.

2.8.1 Monolithic Structure

• 모놀리식 구조는 커널의 모든 기능을 단일 주소 공간에서 실행되는 단일 정적 이진 파일에 넣는다.

• 전통적인 UNIX 운영체제에서 Figure 2.12를 보면 시스템 콜 인터페이스 아래와 물리적 하드웨어 위의 모든 것이 커널이다.
• 커널은 시스템 콜을 통해 파일 시스템, CPU 스케줄링, 메모리 관리 그리고 다른 운영체제 기능을 제공한다.
• 하지만 하나의 주소 공간으로 결합하기에는 엄청나게 많은 기능이다.

• Linux 운영체제에서 응용 프로그램은 일반적으로 커널에 대한 시스템 콜 인터페이스와 통신할 때 glibc 표준 C 라이브러리를 사용한다.
• Linux 커널은 단일 주소 공간에서 커널 모드로 전부 실행된다는 점에서 모놀리식이지만, 런타임 중에 커널을 수정할 수 있는 모듈식 설계를 가지고 있다.
• 하지만, 시스템 콜 인터페이스에는 오버헤드가 거의 없고 커널 안에서의 통신 속도가 빠르기 때문에 여전히 속도와 효율성 측면에서 이 구조를 사용하고 있다.

2.8.2 Layered Approach

• Pros
  • 구현과 디버깅의 간단하다.
    • 층들은 단지 자신의 하위층들의 서비스와 기능들만을 사용하도록 선택된다.
    • 시스템을 계층으로 나누면 시스템의 설계나 구현이 간단해진다.
• Cons
  • 각 계층의 기능을 적절히 정의해야 하는 문제가 있다.

2.8.3 Microkernels

• Mach는 마이크로커널 접근 방식을 사용하여 커널을 모듈화한 운영체제를 말한다.
  • 모듈(module) : 프로그램을 구성하는 구성 요소로, 관련된 데이터와 함수를 하나로 묶은 단위 ⁶
• 이 방법은 모든 중요치 않은 구성요소를 커널로부터 제거하고, 그들을 별도의 주소 공간에 존재하는 사용자 수준 프로그램으로 구현하여 운영체제를 구성하는 방법이다.
• 마이크로커널은 통신 설비 외에 추가로 최소한의 프로세스와 메모리 관리를 제공한다.

• Pros
  • 운영체제의 확장이 쉽다. 모든 새로운 서비스는 사용자 공간에 추가되며, 따라서 커널을 변경할 필요가 없다.
  • 서비스 대부분이 커널이 아니라 사용자 프로세스로 수행되기 때문에 높은 보안성과 신뢰성을 제공한다.
• Cons
  • 가중된 시스템 기능 오버헤드 때문에 성능이 나빠진다.

2.8.4 Modules

이미지 출처 ⁷

• 적재가능 커널 모듈(loadable kernel modules, LKM) 기법에서 커널은 핵심적인 구성요소의 집합을 가지고 있고 부팅 때 또는 실행 중에 부가적인 서비스들을 모듈을 통하여 링크할 수 있다.
• 설계의 주안점은 커널은 핵심 서비스를 제공하고 다른 서비스들은 커널이 실행되는 동안 동적으로 구현하는 것이다.
• ex. CPU 스케줄링과 메모리 관리 알고리즘은 커널에 직접 구현하고 다양한 파일 시스템을 지원하는 것은 적재가능 모듈을 통하여 구현할 수 있다.

References

1. 해시넷 - 패킷 ↩

2. API란? 비개발자가 알기 쉽게 설명해드립니다! - wishket blog ↩ ↩²

3. [운영체제] Lock의 종류 - 박상순 ↩

4. 위키백과 - 데몬 ↩

5. DLL이란? (Dynamic Link Library) by 갓대희 ↩ ↩²

6. TCP School - 분할 컴파일 ↩

7. Interaction of Linux kernel modules with their environment. ↩