OS(Operating System)의 구조

Operating System Structures

• 운영 체제를 여러 관점에서 바라볼 수 있다. 한 가지 관점은 시스템이 제공하는 서비스에 초점을 맞추고, 다른 관점은 사용자와 프로그래머가 사용할 수 있는 인터페이스에 초점을 맞추고, 세 번째 관점은 구성 요소와 그 상호 연결에 초점을 맞추는 것이다.
• 여기서는 운영 체제의 세 가지 측면을 모두 살펴보면서 사용자, 프로그래머 및 운영 체제 설계자의 관점을 보여주고, 운영 체제가 제공하는 서비스, 제공 방법, 디버깅 방법, 이러한 시스템을 설계하기 위한 다양한 방법론에 대해 이야기 하고자 한다.
• 마지막으로 운영체제가 어떻게 만들어지는지, 어떻게 컴퓨터가 os를 시작하는지를 설명한다.

Operating System Services

• os는 프로그램을 실행하기 위한 환경을 제공한다.
• 다양한 os에서 지원하는 특정 서비스는 os마다 다르겠지만 우리는 이를 공통적인 class로 식별할 수 있다.
• 2.1의 그림은 다양한 os의 service와 어떻게 그들이 상호연관 되어있는지를 나타낸다.

1. User interface

• 거의 모든 운영 체제에는 사용자 인터페이스(UI)가 있다.
  • 가장 일반적으로 GUI가 사용된다.
  • 휴대폰 및 태블릿과 같은 모바일 시스템은 터치스크린 인터페이스를 제공하여 사용자가 화면을 손가락으로 밀거나 화면의 버튼을 눌러 선택 항목을 선택할 수 있다.
  • 또 다른 옵션으로는 텍스트 명령과 이를 입력하는 방법(예: 특정 옵션이 있는 특정 형식의 명령을 입력하는 키보드)을 사용하는 명령줄 인터페이스(CLI)가 있다.

2. Program execution

• 시스템에서 프로그램을 로드하고 해당 프로그램을 실행할 수 있어야 한다. 프로그램이 정상적으로 또는 비정상적으로(오류를 나타내는) 실행을 종료할 수 있어야 한다.

3. I/O operations

• 실행 중인 프로그램에는 파일 또는 I/O 장치와 관련된 I/O가 필요할 수 있다.
• 효율성과 protection을 위해서 user는 직접 I/O device를 컨트롤해서는 안되고 os가 I/O를 할 수 있는 수단을 제공해야한다.

4. File-system manipulation

• 파일 시스템은 특히 중요하다.
• 당연히 사용자 프로그램은 파일과 디렉터리를 읽고 쓰며 그 외의 컨트롤을 할 수 있어야한다.
• 일부 운영 체제에는 파일 소유권에 따라 파일 또는 디렉터리에 대한 액세스를 허용하거나 거부하는 권한 관리 기능이 포함되어 있다.

5. Communications

• 하나의 프로세스가 다른 프로세스와 communication하고싶은 상황이 있을 수 있고, 이들 프로세스간의 관계는 같은 컴퓨터 내의 프로세스 또는 다른 컴퓨터 시스템에서 동작하는 (즉 네트워크로 통신중인) 프로세스일 수도 있다.
• communication은 shared memory 또는 message passing → 정의된 포멧으로 만들어진 packet을 프로세스간에 주고받는 형식으로 구현된다.

6. Error detection

• os는 지속적으로 오류를 감지하고 수정해야 한다.
• CPU 및 메모리 하드웨어(메모리 오류 또는 정전 등), I/O 장치(디스크의 패리티 오류, 네트워크 연결 오류 또는 프린터의 용지 부족 등), 사용자 프로그램(산술 오버플로 또는 잘못된 메모리 위치에 대한 액세스 시도 등)에서 오류가 발생할 수 있다.
• os는 각 오류 유형에 대해 적절한 조치를 취해야 한다.

7. Resource allocation

• 여러 프로세스가 동시에 실행 중인 경우 각 프로세스에 리소스를 할당해야 한다.
• CPU cycles나 main memory, file stroage같은 몇몇은 특수한 할당 코드를 가지고 있는 반면에, I/O device와 같은 다른것들은 더 일반적인 요청, 해제 코드가 있을 수 있다.

8. Logging

• 우리는 어떤 프로그램이 얼마나 많이, 그리고 어떤 컴퓨터 자원을 사용하는지를 트레킹 하고싶을 수 있다.
• 이런 기록은 사용 통계를 축적하는 데 사용될 수 있다.

9. Protection and security.

• 다중 사용자 또는 네트워크에 연결된 컴퓨터 시스템에 저장된 정보의 소유자는 해당 정보의 사용을 제어하고자 할 수 있다.
• 여러 개의 개별 프로세스가 동시에 실행되는 경우 한 프로세스가 다른 프로세스나 운영 시스템 자체를 방해할 수 없어야 한다.
• protection은 시스템 리소스에 대한 모든 엑세스가 제어되도록 하는 것이 포함된다.
• 외부인으로부터 시스템을 보호→ user password 입력으로부터 시작
• 또한 네트워크 어댑터를 포함한 외부 입출력 장치를 잘못된 액세스 시도로부터 보호하고 침입 탐지를 위해 이러한 모든 연결을 기록하는 것까지 확장할 수 있다.

System Calls

• system call은 os에서 제공하는 서비스에 대한 인터페이스를 제공한다.
• 이러한 호출은 일반적으로 C 및 C++로 작성된 함수로 사용할 수 있지만, 특정 저수준 작업(예: 하드웨어에 직접 액세스해야 하는 작업)은 어셈블리 언어 명령어를 사용하여 작성해야 할 수도 있다.

cp in.txt out.txt

Application Programming Interface

• 간단한 cp 명령에서도 system call은 많이 사용된다.
• 일반적으로 애플리케이션 개발자는 애플리케이션 프로그래밍 인터페이스(API)에 따라 프로그램을 설계한다.
  • 세 가지 API는 Windows 시스템용 Windows API, POSIX 기반 시스템(거의 모든 버전의 UNIX, Linux 및 macOS 포함)을 위한 POSIX API, Java 가상 머신에서 실행되는 프로그램을 위한 Java API가 있다.

프로그래머가 실제 시스템 호출을 호출하는 대신 API에 따라 프로그래밍하는 것을 선호하는 이유는 뭘까?

API를 사용하여 프로그램을 설계하는 애플리케이션 프로그래머는 자신의 프로그램이 동일한 API를 지원하는 모든 시스템에서 컴파일 및 실행될 것으로 기대할 수 있기때문, 실제로 POSIX API를 사용한다면 대부분의 UNIX 기반의 시스템에서 제대로 동작할 것을 기대할 수 있다.
또한 실제 시스템 호출은 애플리케이션 프로그래머가 사용할 수 있는 API보다 더 상세하고 작업하기 어려울 수 있기 때문

시스템 호출을 처리하는 또 다른 중요한 요소는 런타임 환경(RTE) 이다.

• 런타임 환경(RTE)은 컴파일러 또는 인터프리터뿐만 아니라 라이브러리 및 로더와 같은 기타 소프트웨어를 포함하여 특정 프로그래밍 언어로 작성된 애플리케이션을 실행하는 데 필요한 전체 소프트웨어 제품군이다. RTE는 운영 체제에서 제공하는 system call에 대한 링크 역할을 하는 system call 인터페이스를 제공한다.
• system call 인터페이스는 API에서 함수 호출을 가로채 운영 체제 내에서 필요한 system call을 호출한다. 일반적으로 각 system call에는 번호가 연결되며, 시스템 호출 인터페이스는 이 번호에 따라 system call 테이블을 유지 관리한다.

호출자는 시스템 호출이 구현되는 방식이나 실행 중에 수행하는 작업에 대해 전혀 알 필요가 없이 API를 따르고 해당 시스템 호출의 실행 결과로 운영 체제가 무엇을 수행할지 이해하기만 하면 된다.

system call호출시 원하는 system call의 정의보다 더 많은 정보가 필요한 경우가 많다. 가장 간단한 방법은 레지스터에 파라미터를 전달하는 것, 그러나 경우에 따라 레지스터보다 더 많은 파라미터가 있을 수 있다. 이러한 경우 일반적으로 매개변수는 메모리의 블록 또는 테이블에 저장되고 블록의 주소는 레지스터의 매개변수로 전달된다(2.7).

System call types

• 시스템 콜은 6개의 주요 카테고리로 그룹핑할 수 있다.
• 다음은 시스템 콜을 그룹핑한 것이다.

1. Process control
   1. create process, terminate process
   2. load, execute
   3. get process attributes, set process attributes
   4. wait event, signal event
   5. allocate and free memory
2. File management
   1. create file, delete file
   2. open, close
   3. read, write, reposition
   4. get file attributes, set file attributes
3. Device management
   1. request device, release device
   2. read, write, reposition
   3. get device attributes, set device attributes
   4. logically attach or detach devices
4. Information maintenance
   1. get time or date, set time or date
   2. get system data, set system data
   3. get process, file, or device attributes
   4. set process, file, or device attributes
5. Communications
   1. create, delete communication connection
   2. send, receive messages
   3. transfer status information
   4. attach or detach remote devices
6. Protection
   1. get file permissions
   2. set file permissions

System Services

• 또 다른 관점으로 현대 시스템의 system service을 나눌 수 있다.

1. File management
   • 이러한 프로그램은 생성, 삭제, 복사, 이름 변경, 인쇄, 목록 작성 및 일반적으로 파일과 디렉토리에 액세스하고 조작한다.
2. Status information
   • 일부 프로그램은 단순히 날짜, 시간, 사용 가능한 메모리 또는 디스크 공간, 사용자 수 또는 이와 유사한 상태 정보를 시스템에 요청한다.
   • 일부 시스템은 구성 정보를 저장하고 검색하는 데 사용되는 레지스트리를 지원하기도 한다.
3. File modification
   • 디스크 또는 기타 저장 장치에 저장된 파일의 내용을 생성하고 수정하는 데 여러 텍스트 편집기를 사용할 수 있다.
4. Programming-language support
   • 일반적인 프로그래밍 언어(예: C, C++, Java, Python)를 위한 컴파일러, 어셈블러, 디버거, 인터프리터는 운영 체제와 함께 제공되거나 별도로 다운로드하여 사용할 수 있다.
5. Program loading and execution
   • 프로그램이 어셈블되거나 컴파일된 후에는 실행을 위해 메모리에 로드해야 한다.
   • 시스템은 absolute loaders, relocatable loaders, linkage editors, and overlay loaders을 제공하고, higher-level languages or machine language에 대한 debugging system을 제공할 수 있다.
6. Communications
   • 프로그램은 프로세스, 사용자 및 컴퓨터 시스템 간에 가상 연결을 생성하는 메커니즘을 제공한다. 이를 통해 사용자는 서로의 화면에 메시지를 보내고, 웹 페이지를 탐색하고, 이메일 메시지를 보내고, 원격으로 로그인하거나, 한 컴퓨터에서 다른 컴퓨터로 파일을 전송할 수 있다.
7. Background services
   • 지속적으로 실행되는 시스템 프로그램 프로세스를 서비스, 하위 시스템 또는 데몬이라고 한다.
   • 일반적인 시스템에는 수십 개의 데몬이 있다. 또한 커널 컨텍스트가 아닌 사용자 컨텍스트에서 중요한 활동을 실행하는 운영 체제에서는 이러한 활동을 실행하기 위해 데몬을 사용할 수 있다.

• 대부분의 운영 체제에는 시스템 프로그램과 함께 일반적인 문제를 해결하거나 일반적인 작업을 수행하는 데 유용한 프로그램이 함께 제공됩니다. 이러한 응용 프로그램에는 웹 브라우저, 워드 프로세서 및 텍스트 포맷터, 스프레드시트, 데이터베이스 시스템, 컴파일러, 플로팅 및 통계 분석 패키지, 게임 등이 포함된다.
• 대부분의 사용자가 보는 운영 체제의 모습은 실제 시스템 호출이 아니라 애플리케이션과 시스템 프로그램에 의해 정의된다.

Linkers and Loaders

일반적으로 프로그램은 디스크에 바이너리 실행 파일(예: a.out 또는 prog.exe)로 상주한다. CPU에서 실행하려면 프로그램을 메모리로 가져와 프로세스의 컨텍스트에 배치해야 한다. 여기서는 프로그램을 컴파일하는 단계부터 메모리에 배치하여 사용 가능한 CPU 코어에서 실행할 수 있도록 하는 단계까지 이 절차의 단계에 대해 설명한다.

1. 소스 파일은 물리 주소에 로드될 수 있도록 컴파일러를 통해 object파일로 컴파일된다. 이 파일을 relocatable object file이라고 한다.
2. 이후linker은 이 relocatable object file을 executable 파일로 합친다.
3. loader은 이 파이너리 executable 파일을 메모리에 올리고 cpu core에서 실행될 수 있도록 하는 역할을 담당한다.

지금까지 설명한 프로세스는 모든 라이브러리가 실행 파일에 링크되어 메모리에 로드된다고 가정한다. 실제로 대부분의 시스템에서는 프로그램이 로드될 때 라이브러리를 동적으로 링크할 수 있다. 예를 들어 Windows는 동적으로 링크된 라이브러리(DLL)를 지원한다.
이 접근 방식의 장점은 결국 사용되지 않을 수 있는 라이브러리를 실행 파일에 링크하고 로드하는 것을 피할 수 있다는 것이다.

Why Applications Are Operating-System Specific

• 기본적으로 한 운영 체제에서 컴파일된 애플리케이션은 다른 운영 체제에서 실행할 수 없다. (운영체제에서 지원하는 System call이 다르기 때문에)
• 시스템 호출이 어느 정도 균일하더라도 다른 장벽으로 인해 다른 운영 체제에서 애플리케이션 프로그램을 실행하기 어려울 수 있다.
• 하지만 다음 세 가지 방법 중 하나를 사용하여 애플리케이션을 여러 운영 체제에서 실행할 수 있도록 만들 수 있다.
  • 애플리케이션은 여러 운영 체제에서 사용할 수 있는 인터프리터가 있는 해석 언어(예: Python 또는 Ruby)로 작성할 수 있다.
  • 애플리케이션은 실행 중인 애플리케이션이 포함된 가상 머신이 포함된 언어로 작성할 수 있다. 가상 머신은 해당 언어의 전체 RTE의 일부이다. (ex. java)
  • 애플리케이션 개발자는 컴파일러가 머신 및 운영 체제별 언어로 바이너리를 생성하는 표준 언어 또는 API를 사용할 수 있다. 가장 잘 알려진 예는 POSIX API와 다양한 변형의 UNIX 계열 운영 체제 간에 소스 코드 호환성을 유지하기 위한 표준 세트이다.

java와 인터프린터 언어는 네이티브 애플리케이션에 비해 성능이 상대적으로 떨어지며, 인터프리터는 각 운영 체제의 기능 중 일부만 제공하므로 관련 애플리케이션의 기능 세트가 제한될 수 있다.

이론적으로 이 세 가지 접근 방식은 서로 다른 운영 체제에서 실행할 수 있는 애플리케이션을 개발하기 위한 간단한 솔루션을 제공하는 것처럼 보입니다. 하지만 일반적으로 애플리케이션 이동성이 부족한 데에는 여러 가지 원인이 있으며, 이러한 원인으로 인해 크로스 플랫폼 애플리케이션 개발은 여전히 어려운 과제이다.

애플리케이션 수준에서는 운영 체제와 함께 제공되는 라이브러리에는 GUI 인터페이스와 같은 기능을 제공하는 API가 포함되어 있으며, 한 세트의 API(예: Apple iPhone의 iOS에서 사용할 수 있는 API)를 호출하도록 설계된 애플리케이션은 해당 API를 제공하지 않는 운영 체제(예: Android)에서는 작동하지는 않는다.

시스템의 하위 수준에는 다음과 같은 다른 문제도 존재한다.

1. 각 운영 체제에는 헤더, 명령어 및 변수의 레이아웃을 지정하는 애플리케이션용 바이너리 형식이 있다. 이러한 구성 요소는 실행 파일 내 지정된 구조의 특정 위치에 있어야 운영 체제에서 파일을 열고 애플리케이션을 로드하여 올바르게 실행할 수 있다.
2. CPU에는 다양한 명령어 집합이 있으며, 적절한 명령어가 포함된 애플리케이션만 올바르게 실행할 수 있다.
3. 운영체제는 애플리케이션이 파일 생성 및 네트워크 연결 열기와 같은 다양한 작업을 요청할 수 있는 시스템 호출을 제공한다. 이러한 시스템 호출은 사용되는 특정 피연산자 및 피연산자 순서, 애플리케이션이 시스템 호출을 호출하는 방법, 호출 번호 및 개수, 평균값, 결과 반환 등 여러 측면에서 운영 체제마다 다르다.

이러한 문제를 해결하기 위해 Linux와 거의 모든 UNIX 시스템은 바이너리 실행 파일에 ELF 형식을 채택하고 있다. ELF는 Linux와 UNIX 시스템 전반에 걸쳐 공통 표준을 제공하지만, ELF 형식은 특정 컴퓨터 아키텍처에 종속되지 않으므로 실행 파일이 다른 하드웨어 플랫폼에서 실행된다는 것을 보장하지는 않는다.

아키텍처 수준에서는 애플리케이션 바이너리 인터페이스(ABI)를 사용하여 특정 아키텍처에서 특정 운영 체제에 대해 바이너리 코드의 여러 구성 요소가 어떻게 인터페이스할 수 있는지 정의합니다. 일반적으로 ABI는 특정 아키텍처에 대해 지정됩니다(예: ARMv8 프로세서에 대한 ABI가 있음). 따라서 ABI는 아키텍처 수준에서 API에 해당하는 것입니다. 바이너리 실행 파일이 특정 ABI에 따라 컴파일되고 링크된 경우 해당 ABI를 지원하는 여러 시스템에서 실행할 수 있어야 합니다. 그러나 특정 ABI는 특정 아키텍처에서 실행되는 특정 운영 체제에 대해 정의되기 때문에 플랫폼 간 호환성을 제공하는 데는 거의 역할을 하지 않습니다.

ABI는 주소 폭, 시스템 호출에 매개변수를 전달하는 방법, 런타임 스택의 구성, 시스템 라이브러리의 바이너리 형식, 데이터 유형의 크기 등 낮은 수준의 세부 사항을 지정한다. 특정 아키텍처에 의해 제공되기 때문에 OS에 종속적이다.

Operating-System Structure

최신 운영 체제처럼 크고 복잡한 시스템은 제대로 작동하고 쉽게 수정할 수 있도록 세심하게 설계해야 한다. 일반적인 접근 방식은 하나의 단일 시스템이 아닌 작은 구성 요소 또는 모듈로 작업을 분할하는 것이다. 모든 코드를 main() 함수에 배치하는 대신 로직을 여러 함수로 분리하고 매개변수와 반환값을 명확하게 명시한 다음 main()에서 해당 함수를 호출하는 방식이다.

Monolithic Structure

운영 체제를 구성하는 가장 간단한 구조는 구조가 전혀 없는 것이다. 즉, 커널의 모든 기능을 단일 주소 공간에서 실행되는 단일 정적 바이너리 파일에 배치하는 것이다. 모놀리식(Monolithic) 구조로 알려진 이 접근 방식은 운영 체제를 설계하는 일반적인 기법이다.

그림 2.12에서 볼 수 있듯이 기존 UNIX 운영 체제는 어느 정도 계층화되어 있다고 볼 수 있다. system call interface 아래쪽과 물리적 하드웨어 위쪽의 모든 것이 커널이다. 커널은 시스템 호출을 통해 파일 시스템, CPU 스케줄링, 메모리 관리 및 기타 운영 체제 기능을 제공한다. 요약하자면, 하나의 주소 공간에 엄청난 양의 기능이 결합되어 있는 것이다. Linux 운영 체제는 UNIX를 기반으로 하며 그림 2.13과 같이 유사하게 구조화되어 있다. 애플리케이션은 일반적으로 커널에 대한 시스템 호출 인터페이스와 통신할 때 glibc 표준 C 라이브러리를 사용한다. 리눅스 커널은 단일 주소 공간에서 커널 모드로만 실행된다는 점에서 모놀리식이지만, 런타임 중에 커널을 수정할 수 있는 모듈식 설계가 있다.

Layered Approach

모놀리식 접근 방식은 시스템의 한 부분을 변경하면 다른 부분에 광범위한 영향을 미칠 수 있기 때문에 종종 긴밀하게 결합된 시스템으로 알려져 있다. 이에 반해 느슨하게 결합된 시스템을 설계할 수도 있다. 이러한 시스템은 특정하고 제한된 기능을 가진 별도의 작은 구성 요소로 나뉜다. 이러한 모든 구성 요소가 함께 커널을 구성한다. 이 모듈식 접근 방식의 장점은 한 구성 요소의 변경이 해당 구성 요소에만 영향을 미치고 다른 구성 요소에는 영향을 미치지 않으므로 시스템 구현자가 시스템 내부 작동을 더 자유롭게 생성하고 변경할 수 있다는 것이다.

시스템은 여러 방법으로 모듈화 할 수 있지만 한가지 방법으로는 운영체제가 몇몇의 레이어로 분리되어 구성된 layered approach가 있다. 계층적 접근 방식의 가장 큰 장점은 구성 및 디버깅이 간단하다는 것이다.

계층화된 시스템은 컴퓨터 네트워크(예: TCP/IP) 및 웹 애플리케이션에서 성공적으로 사용되어 왔다. 그럼에도 불구하고 순수한 계층적 접근 방식을 사용하는 운영 체제는 상대적으로 적다. 그 이유 중 하나는 각 계층의 기능을 적절하게 정의하는 데 따르는 어려움 때문이다. 또한 사용자 프로그램이 운영 체제 서비스를 얻기 위해 여러 계층을 통과해야 하는 오버헤드 때문에 이러한 시스템의 전반적인 성능은 좋지 않다.

Microkernels

• UNIX가 확장됨에 따라 커널이 커지고 관리하기 어려워졌다. 1980년대 중반, 카네기 멜론 대학의 연구원들은 마이크로 커널 접근 방식을 사용하여 커널을 모듈화한 Mach라는 운영 체제를 개발했다. 이 방법은 커널에서 불필요한 구성 요소를 모두 제거하고 별도의 주소 공간에 상주하는 사용자 수준 프로그램으로 구현하여 운영 체제를 구조화한다. 그 결과 커널이 좀 더 간소화되었다.
• 마이크로커널의 주요 기능은 클라이언트 프로그램과 사용자 공간에서 실행 중인 다양한 서비스 간의 통신을 제공하는 것이다. 통신은 메시지 전달을 통해 제공된다. 예를 들어 클라이언트 프로그램이 파일에 액세스하려면 파일 서버와 상호 작용해야 한다. 클라이언트 프로그램과 서비스는 직접 상호 작용하지 않는다. 대신 마이크로커널과 메시지를 교환하여 간접적으로 통신한다.
• 마이크로커널 접근 방식의 한 가지 장점은 운영 체제를 더 쉽게 확장할 수 있다는 것이다. 모든 새로운 서비스는 사용자 공간에 추가되므로 결과적으로 커널을 수정할 필요가 없다. 하지만 마이크로커널의 성능은 시스템 기능 오버헤드 증가로 인해 저하될 수 있다. 두 개의 사용자 수준 서비스가 통신해야 하는 경우 별도의 주소 공간에 있는 서비스 간에 메시지를 복사해야 한다. 또한 운영 체제가 메시지를 교환하기 위해 한 프로세스에서 다음 프로세스로 전환해야 할 수도 있다.

Building and Booting an Operating System

특정 머신 구성을 위해 특별히 운영 체제를 설계, 코딩 및 구현할 수 있다. 그러나 일반적으로 운영 체제는 다양한 주변 장치 구성을 갖춘 모든 종류의 머신에서 실행되도록 설계된다.

System Boot

• 운영 체제가 생성된 후에는 하드웨어에서 사용할 수 있도록 만들어야 한다 하지만 하드웨어는 커널의 위치나 커널을 로드하는 방법을 어떻게 알 수 있을까? 커널을 로드하여 컴퓨터를 시작하는 프로세스를 시스템 부팅이라고 함. 대부분의 시스템에서 부팅 프로세스는 다음과 같이 진행된다.

1. 부트스트랩 프로그램 또는 부트 로더로 알려진 작은 코드 조각이 커널을 찾습니다.
2. 커널이 메모리에 로드되고 시작됩니다.
3. 커널이 하드웨어를 초기화합니다.
4. 루트 파일 시스템이 마운트됩니다.

• 일부 컴퓨터 시스템은 다단계 부팅 프로세스를 사용한다: 컴퓨터의 전원을 처음 켜면 BIOS라고 하는 비휘발성 펌웨어에 있는 작은 부트 로더가 실행된다. 이 초기 부트 로더는 일반적으로 부트 블록이라고 하는 고정 디스크 위치에 있는 두 번째 부트 로더를 로드하는 것 외에는 아무것도 하지 않는다.
• 일반적으로 부트스트랩 프로그램은 단일 디스크 블록에 들어가야 하므로 단순한 코드이며 디스크의 주소와 나머지 부트스트랩 프로그램의 길이만 알고 있다. 최근의 많은 컴퓨터 시스템은 BIOS 기반 부팅 프로세스를 UEFI(통합 확장 가능한 펌웨어 인터페이스)로 대체했다. UEFI는 64비트 시스템 및 대용량 디스크에 대한 더 나은 지원을 포함하여 BIOS에 비해 몇 가지 장점이 있다. 가장 큰 장점은 UEFI는 단일의 완전한 부팅 관리자이며 따라서 다단계 BIOS 부팅 프로세스보다 빠르다는 것이다.

참고
운영체제 공룡책