운영체제

운영체제 구조

Seonyoung Jeong 2021. 8. 17. 16:09

운영체제 디자인

  • Mechanism
    - 무엇을 어떻게 할 것인가?
    - ex) algorithm 종류, data structure
  • Policy
    - 무엇이 되게 할 것인가?

★ Mechanism과 Policy를 분리하는 것은 중요한 문제!

Layering

  • OS의 복잡도를 낮추기 위한 방안
  • 각 레이어는 정의가 명확한 함수들로 이루어져있으며, 하나의 layer는 인접한 layer와만 통신이 가능하다.
  • 장점
    - 각 layer마다 기능을 수정을 할 때 다른 layer와 독립적이다.
  • 단점
    - 분리가 제대로 되어있지 않기 때문에 만약 A에서 문제가 발생하면 다른 레이어까지 문제를 끌고가게 된다는 단점이 있다.

User mode와 Kernel mode

  • Kernel mode
    - 모든 권한을 가진 실행 모드로써 운영체제가 실행된다.
    - Privilege 명령어 실행과 레지스터 접근이 가능하다.
    - ex) I/O 장치 제어 명령어, memory management register - CR3
  • User mode
    - 커널 모드에 비해 낮은 권한을 가진 실행 모드로 우리가 자주 쓰는 애플리케이션이 실행되는 모드이다.
    - Kernel mode에 비해 권한이 낮아 privilege 명령어실행은 불가능하다.
  • 실행 모드 전환 (execution mode switch)
    - CPU의 실행 모드 설정은 시스템 보호가 목적
    - User mode에서 실행중인 애플리케이션이 kernel mode의 권한이 필요한 서비스를 받기 위해서는 전환 방법이 필요하다. 그 방법이 바로 system call!!
    - ex) 내가 친구한테 카톡을 보내면 network로 나가야한다. 이 때 user mode에서 kernel mode로 바뀌는데 이 때 system call을 통해 execution mode switch가 일어난다.

System Call

[ System call 이란? ]

  • User mode에서 Kernel mode로 진입하기 위한 통로 ex) Open(2), Write(2), Msgsnd(2), Shm(2) 등등,,,, 여기서 2는 system call을 의미한다. (Open 함수에는 여러 종류가 있는데 괄호 안에 2를 넣으면 system call 종류의 open 함수임을 구별할 수 있다.)
  • 주로 C/C++와 같은 고급 언어로 작성돼있음.
  • 프로그램에 접근할 때는 direct system call보다 고급 언어 API를 이용하고, 그 API안에는 여러 개의 system call이 들어있다.
  • 왜 System call을 직접적으로 사용하지 않고 API를 사용할까?
    - API는 시스템 콜 사용을 위한 간단한 수단을 제공하고 구현 상세 사항을 숨길 수 있기 때문이다.

[ System call Interface ]

  • System call interface는 시스템 콜 넘버와 연관된 테이블을 유지하고있으며 OS kernel에서 찾는 system call을 실행시켜 그와 관련된 결과 값과 상태를 return하는 역할을 한다.

 

[ System call 처리 과정 ]

 

[ System call Parameter Passing (argument 처리) ]

  • Parameter passing에는 세가지 방법이 있다.
  • 위의 그림은 레지스터를 통해 pass하는 간단한 방법이다.
  • 경우에 따라 register의 크기보다 더 많은 parameter를 pass해야할 때가 있는데, 이 때는 block이나 table, memory 등을 이용하기도 한다.
  • 그리고 다른 경우에 따라서 스택을 이용하기도 한다.
  • Block과 stack은 parameter 패스를 할 떄 크기나 길이 제한이 없기 때문에 유용하다.

운영체제 구조 종류

운영체제의 구조 종류에는 Simple structure, layered structure, microkernel structure, modular kernel structure 총 네가지가 있다. 각 구조의 장단점을 알아보도록 하자.

 

[ Simple structure ]

(1) MS-DOS

  • Policy : 좁은 공간에서 최대한 많은 기능을 제공하기
  • MS-DOS가 Simple structure의 예시라고 볼 수 있는데 그림과 같이 각각의 인터페이스와 기능들이 제대로 분리되어있지 않다. 그래서 하나가 망가지면 시스템 전체가 망가지게 되는 큰 단점이 있다.
  • 또한 MS-DOS의 레이어링은 불완전했다는 단점이 있다.

(2) UNIX

  • UNIX OS는 시스템 프로그램과 커널로 이루어져 있다.
  • 그림에서 알 수 있다시피 커널과 하드웨어 사이에 모든 기능들이 들어있다.
  • 이 기능들은 너무 많기 때문에 kernel의 크기 너무 크다는 단점과 함께 관리하기 힘들다는 단점이 있다.

 

[ Layered Strucure ]

  • OS가 여러개의 layer(level)로 분리된 형태를 띈다. 가장 아랫단계인 0번 레이어는 하드웨어를 뜻하고, 가장 높은 단계인 N번 레이어는 User Interface를 가리킨다.
  • 상위 계층에서는 하위 계층을 호출해 하위 계층의 기능을 사용할 수 있다.
  • 장점
    - OS 구현과 디버깅이 단순하다.
    - 각 레이어는 자기보다 낮은 단계의 레이어에서 제공하는 연산만을 사용하기 때문에 그 연산이 어떻게 구현되었는지를 알 필요가 없다.
  • 단점
    - 레이어는 자기보다 낮은 레이어의 연산만 사용할 수 있다는 특징때문에 careful planning이 필요하다.
    - 자기자신보다 n단계 낮은 레이어의 기능을 사용하기 위해서는 n단계를 모두 거쳐서 내려가야한다.

 

[ Monolithic Kernel ]

  • 커널이 사용자와 같은 주소 공간에 위치하므로 message passing이 필요하지 않다.
  • 주소 공간을 커널 코드와 사용자가 나누어서 사용한다.
  • 장점
  • 시스템 콜 및 커널 서비스 간의 데이터 전달 시에 오버헤드가 적다.
  • 단점
    - 모든 서비스 모듈이 하나의 바이너리로 이루어져 있기 때문에 일부 수정이 전체에 영향을 미친다.
    - 각 모듈이 유기적으로 연결되어 있어 커널 크기가 커질수록 유지 보수가 어렵다.
    - 한 모듈의 버그가 시스템 전체에 영향을 끼친다.
    - 그래서 Monolithic kernel에 있어서 가장 1차적인 attack surface가 바로 "System call"

 

[ Microkernel System Structure ]

  • 핵심적인 기능만을 최소로 담아 만든 커널
  • 커널 서비스를 기능에 따라 모듈화하여 각각 독립된 주소 공간에서 실행한다. 이러한 모듈을 커널 서버라고 하며, 이 서버들은 독립된 주소 공간으로 구현된다.
  • 마이크로 커널은 서버들 간의 통신, 애플리케이션의 서비스 콜 전달과 같은 단순한 기능만을 제공한다.
  • 장점
    - 각 커널 서버가 독립되어 있어 서로 간의 의존성이 낮다. ⇒ monolithic 커널보다 독립적인 개발이 가능하고, 커널의 개발 및 유지 보수가 상대적으로 용이함.
    - 커널 서버 각각의 재시작/종료가 가능하다. 문제 있는 서비스는 서버를 재시작하여 해결하기 때문에 monolithic 커널보다 안정적이다.
    - 서버 코드가 protected memory에서 실행되므로 검증된 S/W 분야에 적합하다.
    - 기능을 확장하기가 쉽다.
    - 커널 모드에서 적은 코드가 실행되기 때문에 더 안정적이다.
  • 단점
    - Monolithic 커널보다 성능이 낮아 실무보다는 연구용으로 많이 쓰인다.
    - user space와 kernel space간의 통신에서 오버헤드가 발생한다.
  • Monolithic kernel과 Microkernel 블록 I/O 처리 비교

Monolithic kernel에서는 서비스가 같은 커널을 공유하기 때문에 데이터 전달 시의 오버헤드가 적다. 그러나 Microkernel의 경우는 Applicatoin, VFS, EXT3, Device driver 각각의 주소가 다르기 때문에 데이터 전달에 있어서 오버헤드가 크다. 이 외에도 monolithic kernel과 microkernel의 차이는 다양하다.

 

 

가상화 (Virtualization)

[ 가상화의 등장 ]

  • 1960년대부터 존재했으나 그 당시에는 가상화가 되지 않은 환경이었어서 활용되지 못했음.
  • 그러나 2003년 Xen의 등장으로 하이퍼바이저 계층이 도입되었다.
  • 최근에 등장한 5G는 네트워크 가상화를 도입한 것이다.

 

[ 가상화의 이점 ]

  • Consolidation
    그림을 바탕으로 설명해보자. 왼쪽은 기존에 하드웨어와 OS가 1:1의 관계를 가지는 가상화가 도입되지 않은 못브이다. Hardware 하나당 비용이 200이라고 하면 왼쪽은 총 400이라는 비용이 필요하게 된다. 그러나 오른쪽 그림과 같이 Hardware 하나에 가상화를 도입하게 되면 200이라는 비용으로 하드웨어와 OS가 1:2의 관계를 가질 수 있게 된다. 가상화가 도입됨으로써 자원 할당이 자유로워지고 하드웨어 비용이 줄어든다.
  • Decoupling
    그림과 같이 하드웨어와 소프트웨어의 의존성을 제거함으로써 소프트웨어의 이식성이 증가한다. ex) 애플리케이션의 수정 없이 다른 하드웨어에서도 실행이 가능해진다.

 

  • Isolation
    Guest OS가 고립적이기 때문에 시스템 신뢰성이 올라간다. ex) 하나의 Guest OS가 재부팅하더라도 다른 Guest OS는 운영이 가능하다.

 

Hypervisor

  • Hypervisor란?
    - 게스트 OS와 하드웨어 사이에 위치하며, 가상화된 컴퓨터 하드웨어 자원을 제공하기 위한 관리 계층이다.
    - 게스트 OS는 hypervisor가 제공하는 가상화된 하드웨어 자원을 이용하는 운영체제이다. 이 게스트 OS는 hypervisor로부터 할당 받은 자원에 대해서만 접근 및 수행이 가능하다.
  • 장점
    - 하나의 물리 컴퓨터에서 여러개의 OS 운용이 가능하므로 한 서버에서 다양한 서비스를 동시에 제공받을 수 있다.
    - 실제 컴퓨터와 다른 형태의 명령어 집합 구조를 제공하기 때문에 다른 하드웨어 환경에서 컴파일 된 게스트 OS 및 응용프로그램도 실행이 가능하다.
  • 단점
    하드웨어를 직접적으로 사용하는 다른 운영체제에 비해 성능이 떨어진다. ⇒ 반가상화로 성능저하 문제를 해결 가능 ⇒ 게스트 OS의 하드웨어 의존적인 코드에 대한 수정이 필요한데 이 부분에서 높은 기술력이 필요하고, OS이 소스가 공개되지 않았다면 게스트 OS로 수정이 불가능하다는 문제점이 있다.운영체제 디자인