Chapter 2. 운영체제 구조

안녕하세요 조엘입니다! 운영체제 2단원에 대해 공부해 보았습니다.

Abraham Silberschatz의 Operating System Concepts 10th edition과 학부 수업을 듣고 정리한 내용입니다. 오개념이 있다면 알려주세요~~

 

<운영체제 서비스>

운영체제는 다음과 같은 기능을 제공할 수 있어야 한다.

 

-사용자 인터페이스: CLI, GUI, 터치스크린 등

-프로그램 수행: 프로그램을 메모리에 적재해 실행할 수 있어야 한다. 

-입출력 연산: 프로그램이 입출력을 요구하면 OS가 제어를 넘겨받아 처리해줘야 한다.

-파일 시스템 조작: 파일 조회, 파일 수정, 파일 권환 관리 등

-통신: 프로세스 사이의 정보를 교환해야 할 경우, 공유 메모리(동일 컴퓨터의 프로세스들)와 패킷을 통한 메시지 전달(네트워크로 연결된 컴퓨터의 프로세스들)로 이루어진다. 

-오류 탐지: OS는 항상 오류를 의식하고 있어야 하며, 각 오류에 적당한 조치를 해주어야 한다. 

-자원 할당: 다수의 작업 실행 시 자원의 할당이 필수적인데, CPU의 효율적 사용을 위한 CPU 스케줄링 루틴, 속도, 필수 프로세스, 프로세스 처리 코어 갯수 등의 여러 요인을 고려해야한다. 

-기록 작성: 어떤 프로그램이 어떤 컴퓨터 자원을 사용했는지 추적해야한다. 시스템 관리자에게 소중한 정보가 된다.

-보호: 한 프로세스가 타 프로세스나 OS를 방해해서는 안 된다. 시스템 자원에 대한 접근이 통제되도록 해야한다. 

-보안: 네트워크 어댑터 등과 같은 외부 입출력 장치들을 부적합한 접근 시도로부터 지키고, 침입의 탐지를 위해 모든 접속을 기록해야 한다. 

 

<명령 인터프리터>

명령 인터프리터는 사용자가 처음 로그온 할 때 수행되는 특수한 프로그램으로, 사용자가 지정한 명령을 가져와 그것을 수행한다. 이러한 인터페이스를 제공하는 프로그램을 셸이라고 한다. 

User와 kernel 사이에서 user의 명령을 해석하고, 처리 결과를 뿌려주는 프로그램이라고 요약할 수 있다. 

 

명령어들은 두 가지 방식으로 구현될 수 있다. 

  1. 명령 인터프리터 자체가 명령을 실행할 코드를 가지는 경우

     자신의 코드 한 부분으로 분기하며, 그 코드 부분이 매개 변수를 설정하고 적절한 시스템 콜 수행

  2. 시스템 프로그램에 의해 명령을 구현하는 경우

     명령 인터프리터는 명령을 모른다. 단지 메모리에 적재되어 실행될 파일을 식별한다. 

     (ex. rm test.txt의 경우, rm 시스템 프로그램 파일을 찾아, 그 파일을 메모리에 적재한다. 매개변수로 test.txt가 넘어가 고 파일이 삭제된다.)

 

<시스템 콜>

시스템 콜은 OS에 의해 사용가능하게 된 서비스에 대한 인터페이스 제공 방식이다. 간단한 프로그램이라도 초당 수천개의 시스템 콜을 수행, 즉 OS의 기능을 사용하게 된다. 

 

응용 프로그램 개발시, API(응용 프로그래밍 인터페이스)에 따라 프로그램을 설계한다. API는 각 함수로 전달되어야 할 매개변수들과 프로그래머가 기대할 수 있는 반환값을 포함하여, 응용 프로그래머가 사용가능한 함수의 집합이다. 매개변수를 저장하는 방법은 2가지가 있는데, 매개변수가 5개 이하일 경우 CPU 레지스터에 저장되고, 5개 초과일 경우 stack에 메모리 블록으로 저장된다. 

 

프로그래머는 OS가 제공하는 코드의 라이브러리를 통해 API를 활용하게 되고, 따라서 API를 구성하는 함수들은 응용 프로그래머를 대신하여 시스템 콜을 수행한다고 보면된다.

 

API를 사용함으로써 호환성이 높아진다. 

 

<링커와 로더>

작성된 소스파일은 컴파일을 통해 임의의 물리 메모리 위치에 적재되도록 설계된 오브젝트 파일이 된다. 오브젝트 파일은 링크를 통해 이진 실행 파일이 된다. 이진 실행 파일은 로더를 통해 메모리에 적재된, CPU 코어에서 실행 할 수 있는 상태로 만든다. 

 

셸에서 main 프로그램을 실행하는 과정을 생각해보자. (./main)

1. fork() 시스템 콜을 사용해 프로그램을 실행하기 위한 새 프로세스를 생성한다. 

2. exec() 시스템 콜로 로더를 호출한다. exec()에 실행파일의 이름을 전달한다. 

3. 로더는 새로 생성된 프로세스의 주소 공간을 사용하여, 지정된 프로그램을 메모리에 적재한다. 

 

앞서 언급된 과정들은 모두 라이브러리가 링크타임에 링크되어 메모리에 적재되었을 경우를 가정한다. 

 

동적 링킹 라이브러리도 존재하는데, 이는 링크타임에 링커가 재배치 정보만 삽입해주며, 프로그램의 런타임 시 조건부 링크되며 필요시 적재된다. 

 

오브젝트 파일 및 실행파일은 표준화된 형식을 갖는다. 프로그램에서 참조되는 함수/변수에 대한 메타데이터를 포함하는 기호테이블 역시 안에 포함이 되어있다. 각 OS 마다 이 표준화된 형식이 다르다. 

UNIX/Linux는 ELF 형식, Windows는 PE 형식, MacOS는 Mach-O 형식을 갖는다. 

Linux는 ELF, Windows는 PE

 

<응용 프로그램이 운영체제마다 다른 이유>

각 OS는 고유한 시스템 콜 집합을 제공한다. 각 OS마다 응용 프로그램의 헤더, 명령어, 변수 배치 방법이 다르고, system call 호출 방법, 번호, 의미, 결과 등이 상이하다. 

 

<운영체제 구조>

대표적인 운영체제의 구조들을 알아본다. 

1. 모놀리식 구조

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

  장점: 성능이 좋음(오버헤드도 거의 없고, 통신도 빠름) / 단점: 확장이 어려움

 

2. 계층적 접근

  특정 기능 및 한정된 기능을 가진 개별적인 구성 요소들로 나눔. 

  장점: 구현/디버깅이 간편함. 각 층은 자신보다 하위 수준의 층에 의해 제공된 연산들만 사용해 구현한다. (컴퓨터 네트워크의 TCP/IP, 웹 프로그래밍에서 성공을 거둔 방식)

  단점: 오버헤드가 크다. 각 계층마다 기능을 나누기가 모호하다. 

 

3. 마이크로 커널

  커널에는 정말 중요한 구성 요소만 남겨놓고, 나머지 기능은 유저 프로그램으로 구현한다. 

  장점: 확장이 쉽다 / 단점: 가중된 시스템 기능 오버헤드로 인한 성능 저하

 

4. 모듈

  커널은 핵심적인 구성요소의 집합을 갖고, 부가 서비스는 모듈을 통해 커널이 실행되는 동안 동적으로 링크한다. 마이크로 커널과 유사해 보이는데, 메시지 전달을 호출할 필요가 없기 때문에 더 효율적이다. 

 

5. 하이브리드 시스템

  위에 소개한 구조들을 혼용해서 사용한다. Linux는 모놀리식 구조와 모듈을 섞어서 사용한다.