[운영체제] #3. 운영체제 구조 (2)

목차

• System Structure
• OS Design Principle
  • Mechanism
  • Policy
• Methods for Operating System Design
  • Layering
  • Modularity
• Kernel Designs
  • Monolithic Kernel
  • Micro Kernel
  • Hypervisor

 

System Structure

• 운영체제는 규모가 매우 크고 복잡한 소프트웨어
• 좋은 설계를 통해 쉬워지는 것들
  • 개발
  • 수정 및 디버깅
  • 유지 보수
  • 확장
• 디자인 목표 중에 좋은 것 : 설계하고자 하는 시스템의 목적과 관계가 있음

 

Methods for Operating System Design

OS Design Principle

• Policy 
  • 시스템이 어떤 일을 수행할지를 정의하는 고수준의 목표
  • 예시
    • CPU 스케줄링 정책 : 어떤 프로세스가 CPU 를 먼저 사용할 것인가?
    • 데이터 접근 제어 : 어떤 사용자가 파일을 읽거나 쓸 수 있는 권한을 가질 것인가?
• Mechanism
  • Policy 를 구현하기 위한 구체적인 방법 또는 알고리즘
  • 예시
    • 스케줄링 메커니즘 : 각 프로세스의 우선순위를 비교하는 알고리즘
    • 데이터 접근 메커니즘 : 파일 권한 정보를 읽고 요청한 사용자의 권한과 비교하는 방식
• Policy 와 Mechanism 을 분리해서 운영체제의 설계를 더 유연하고 확장 가능하게 한다. (Module 화)

 

Layering

• OS 의 복잡도를 낮추기 위한 설계 방식
• 각 Layer 는 Well-Defined 함수로 이루어짐
• 하나의 Layer 는 인접한 Layer 와만 통신
• Layer 간 기능이 독립적이여서 유지보수와 확장이 쉬움
• 문제점
  • Layer 가 많아질 수록 여러 Layer 를 거쳐야 하므로 Overhead 가 발생할 수 있음

 

Layering vs Modularity

 

• Modularity : 시스템을 기능별로 독립적인 모듈로 나누어 관리하여 설계의 독립성과 확장성을 높임
• Layering : 계층적 구조를 통해 설계의 논리적 흐름을 강조

 

User Mode 와 Kernel Mode

• CPU 는 2가지 이상의 실행 모드 => System Protection 
  • Kernel Mode : 운영체제 커널이 실행되며 하드웨어 자원에 완전한 접근 권한을 가짐
    ex) 메모리 관리, 디스크 제어, 프로세스 관리
  • User Mode : 일반 어플리케이션이 실행되며, 하드웨어에 제한된 접근 권한만 가짐
    ex) 텍스트 편집기, 웹 브라우저
  • 실행 모드 전환 : User Mode 에서 실행 중인 Application 이 Kernel Mode 기능(예: 파일 읽기) 를 request 하면, System Call 을 통해 전환

 

System Call

: User Mode 에서 Kernel Mode 로 진입하기 위한 통로

 

1. User Mode 에서 System Call 요청
2. System Call Table 에서 해당 구현으로 mapping
3. Kernel Mode 로 전환
4. Kernel Mode 에서 작업 처리
5. User Mode 로 복귀 : 처리 결과를 사용자 프로그램으로 반환

시스템 콜은 정확하게 어떻게 이루어져 있을까?

1. 시스템 콜 번호(13)와 파라미터(x) 가 register 를 통해 OS 에 전달된다.
2. OS 는 System Call Table 에서 번호에 해당하는 code 를 찾아서 실행한다. (파라미터를 사용해 작업을 처리)
   ex) X : /home/user/test.txt or 메모리 크기 1024
   system call : 13 (파일 읽기)
   13 -> open_file () 함수 mapping 
   open() 호출 => open_file("/home/user/test.txt") 실행 
   
   

 

 

Kernel Designs

Monolithic Kernel

• 모든 커널 서비스가 하나의 주소 공간에서 실행됨
• App 은 자신의 주소 공간에 커널 코드 영역을 mapping 하여 kernel 서비스를 이용
• H/W 계층에 관한 단일한 Abstraction 을 정의

 

• 장점 : 성능이 뛰어나고 Overhead 가 적음
• 단점 : 커널 크기가 크고, 오류가 발생하면 전체 시스템이 영향을 받을 수 있음

 

Micro Kernel

• kernel 서비스를 작은 module 로 분리하여, 각 모듈 (서버) 을 독립적인 프로세스로 실행
• kernel 에는 최소한의 기능만 포함
• 서버 코드가 Protected Memory 에서 실행됨 => 검증된 S/W 분야에 적합
• 문제 있는 서비스는 서버를 재시작하여 해결

• 장점 : 안전성과 보안성이 뛰어남, 서비스가 분리되어 오류가 전체 시스템에 영향을 주지 않음
• 단점 : 모듈 간 통신(IPC) 에 따른 성능 저하 
  
  

Monolithic Kernel vs. Micro Kernel

Micro Kernel 은 서비스를 모듈로 분리하여 System call 을 통해 kernel 의 IPC 를 통한 다음 서비스 Upcall 한다.

반면에, Monolithic Kernel 은 하나의 kernel 에 서비스가 같은 메모리 주소에 있어서 System call 은 한번만 호출되며 kernel 에 있는 다른 서비스들이 순차적으로 function call 이 일어난다.

 

Hypervisor

: 가상화 계층으로 하나의 물리적 컴퓨터에서 여러 개의 가상 머신을 실행할 수 있도록 지원

• Guest OS 와 H/W 사이에 위치
• 각 Guest OS 들은 각각 서로 다른 가상 머신에서 수행되며, 서로의 존재를 알지 못함
• 각 Guest OS 간의 CPU, Memory 등 시스템 자원을 분배하는 등 최소한의 역할을 수행
• 장점
  • 하나의 하드웨어에서 여러 OS 를 동시에 실행 가능
  • 실제 컴퓨터가 제공하는 것과 다른 형태의 명령어 집합 구조를 제공
• 단점
  • 가상화 계층이 추가되면서 H/W 를 직접적으로 사용하는 다른 OS 에 비해 성능이 떨어짐
    => 반가상화(Para-Virtualization) 로 성능 저하 문제를 해결하려 함
    단, Guest OS 의 H/W 의존적인 코드에 대한 수정이 요구됨 
    • 높은 기술적인 능력 필요
    • OS 소스 코드가 공개 되어야 한다는 가정이 있어야 함