[운영체제] 2. 시스템구조

임호연·2021년 5월 21일

기록

목록 보기

2/20

본 포스팅의 내용은 Operating System Concepts 10th의 내용을 토대로 작성되었습니다.

시스템 콜

시스템 콜 인터페이스

read from file, write to file와 같은 API만 잘 정의한다.

매개변수 전달 방법

레지스터에 시스템 콜의 argument를 저장
system call을 레지스터의 위치와 함께 호출
system call routine에서 register의 정보를 fetch

만약, X의 개수(argument의 개수) 가 너무 많다면, 스택 혹은 블록 메모리에 저장하고 다시 뽑아낸다.

커널 안에서 실제 시스템콜의 동작 과정

한가지 중요한 점은, 이러한 매개변수는 커널에 복사한 후 사용해야 한다.

만약, 유저의 메모리에서 그대로 가져다 쓰게 되면, 커널이 argument를 verify 한 후 유저가 invalid argument로 악의적으로 바꾸는 attack을 할 수가 있기 때문이다.

시스템 콜 잡지식

한 명령어 실행 : 명령어 하나 실행하고 trap을 건다. 디버거에서 사용된다.
보호 : 내가 아는 permission

시스템 서비스

백그라운드 서비스: 시스템이 정지될 때 까지 계속해서 실행되는 프로세스

데몬, 서비스, 서브시스템 등의 이름으로 불린다.

운영체제의 권한을 이용한 작업을 사용자 공간에서 데몬이 대신 돌려줄 수 있다.

링커와 로더

컴파일러가 소스파일을 명령어 집합이며 재배치 가능한, 기계어인 오브젝트 파일로 만든다.
링커는 오브젝트 파일을 엮어 하나의 이진실행파일로 결합한다. 이 과정에서 다른 라이브러리가 포함될 수 있다. EXT파일을 생성한다.
로더는 링커의 결과인 실행파일을 메모리에 올리도록 한다.

fork and exec that ext file..
DLL

윈도우에서 사용, 실행파일에 포함된 게 아니라, 로더에 올릴 때 동적으로 링킹된다.

메모리 절약을 할 수 있다.
ELF(Executable and Linkable Format)

단순히 말하면, 유닉스 실행 파일입니다.

윈도우에서는 PE(Portable Executable)

실행 파일에서는, 프로그램을 시작시키기 위한 주소 등이 있겠지.

모놀리식 구조와 마이크로 구조

모놀리식 구조

단점이 있어도, 속도와 효율성 면에서 따라올 자가 없다. 하드웨어와 시스템 콜 사이에 있는 것이 커널

레이어 인터페이스

디버깅 할 때 생각해 봐라. 낮은 층부터 해 나가면, 어떤 문제가 생겼을 때 아래 층에서는 문제가 없었다고 하면 위 층에서 문제가 있었다는 것을 알 수 있다.

물론, api를 정해야 하는 등의 오버헤드는 있습니다.

마이크로 커널

커널의 기능이 여러 개의 서버로 분할된다.
크래시가 나도 커널이 죽지 않는다.
운영체제의 서비스 대부분이 유저 공간에서 실행된다.
확장성이 용이하다.
이식성도 괜찮다.

일부분만 바꾸면 되기에
커널 내부에서, 메시지를 교환할 때 다른 프로세스로 전환해야 할 수도 있다. 이런 오버헤드가 있긴 하겠다.
모놀리딕 커널, 마이크로 커널
1. 모노리틱 커널과 마이크로 커널 그리고 하이퍼바이저에 대하여 다음을 설명하시오.
2. 구조상의 차이점을 구체적으로 제시하시오.
  (1)모놀리딕 커널과 마이크로 커널 비교
  -구조상 비교
  모놀리딕 커널은 대부분의 시스템 주요 기능이 커널에 구현되어 있다. 반면에, 마이크로 커널은
  스케쥴링 등 정말 최소한의 기능만 커널에서 구현되고, 나머지 필요한 커널의 기능은 서버 프로세스
  형태로 존재한다.
  예를 들면, 모놀리딕 커널 구조에서 디바이스 드라이버 관련 기능을 커널에 구현하지만 마이크로
  커널에선 서버 프로세스 형태로 구현한다.
  -안정성
  모놀리딕 커널 기반 운영체제는 커널의 기능을 이용하다가 오류가 발생하면 시스템이 멈추는 등
  심각한 문제가 생긴다. 하지만 마이크로 커널 기반 운영체제의 경우엔 운영체제 핵심 기능과 따로
  존재하기 때문에 마이크로 커널 서버 프로세스에 문제가 생겨도 전체 시스템에는 크게 지장이 없다.
  -확장성
  모놀리딕 커널은 여러 커널들이 얽혀 있기 때문에 확장이 어렵지만, 마이크로 커널은 프로세스만
  따로 만들면 되기 때문에 비교적 쉽다.
  (2)하이퍼바이저
  하이퍼바이저는 하드웨어를 가상화하여 하나의 프로세스 형태로 제공하는 것이다.
  마이크로 커널과 모놀리딕 커널 모두 하드웨어 기능을 다른 프로세스들이 사용하게 하기 위해
  존재하지만, 하이퍼바이저는 단지 소프트웨어를 통해 가상화된 하드웨어를 운영체제에 제공한다는
  점에서 다르다고 할 수 있다.
3. 성능상의 차이점을 설명하고, 구체적인 이유를 제시하시오.
  (1)마이크로 커널 동작 방식
  1. 클라이언트 프로세스에서 요청을 메세지 큐에 담는다.
  2. 서버 프로세스는 메세지 큐에 있는 클라이언트 프로세스의 요청을 확인하기 위해, 지속적으로
  폴링하거나 인터럽트를 통해 확인한다.
  3. 서버프로세스가 실행되기 위해 context switching 이 일어난다.
  4. 서버프로세스가 클라이언트 프로세스의 요청을 완료하고 나면, 이를 확인하기 위해 클라이언트
  프로세스는 메시지 큐를 폴링하거나 인터럽트를 통해 서버에 요청한 작업이 완료되었음을 확인한다.
  1. 이후에 context switching 을 통해 다시 클라이언트 프로세스가 실행된다.
  (2)모놀리딕 커널 동작 방식
  1. 모든 프로세스는 메모리에 커널영역을 포함하고 있다. 따라서, 만약 프로그램에서 커널의 기능이
  실행되어야 한다면, 마치 함수처럼 커널 메모리 영역의 서브루틴을 호출한다.
  2. 프로세스 레지스터에 커널 서브루틴 호출 시 필요한 인자를 입력하고, 서브루틴을 시작한다.
  3. 서브루틴이 끝나면, 레지스터에 결과를 저장한다.
  (3)성능 비교
  모놀리딕 커널은 레지스터를 이용해 데이터를 교환하지만, 마이크로 커널은 하드웨어에 의해 바로
  수정될 수 없는 메시지 큐라는 프로그램적인 요소를 사용한다.
  레지스터를 이용한 데이터 교환은 추가적인 오버헤드가 거의 없다. 그러나 메시지 큐 방식을
  사용하면 메모리에 데이터를 저장해야 하고 여러 프로세스가 계속해서 접근해야 하기 때문에,
  레지스터를 이용한 방식보다 성능이 좋지 않을 수밖에 없다.
  -마이크로 커널은 커널 서버 프로세스 실행 시 프로세스간 데이터를 전송하는 개념을 사용하기
  때문에, 이 전송 시간이 성능에 영향을 미칠 수 있다.
  -커널 서버 프로세스와 실행하고 있는 클라이언트 프로세스가 서로 다른 프로세스이기 때문에
  context switching 에 따른 오버헤드도 더 많이 생길 것이다.
  (4)하이퍼바이저
  OS 레벨의 명령어를 가진 프로그램을 실행하면, 하드웨어로 보내는 명령을 하이퍼바이저를 통해
  변환하고 다시 실제 하드웨어로 전송해야 한다. 이 과정에서 성능이 하락한다.
  3)FCFS 와 priority scheduling 이 마이크로 커널에서도 사용될 수 있는지 논하시오. 있다만 어떻게
  동작을 하고, 사용될 수 없다면 왜 사용할 수 없는지 설명하시오.
  FCFS 를 사용할 수 있다 단, 커널 프로세스를 사용하는 클라이언트 프로세스라면 여러
  조건이 필요하다. 먼저, 클라이언트 프로세스가 커널 서버 프로세스를 사용할 땐 해당
  커널 서버 프로세스가 다른 프로세스보다 먼저 실행되어야 한다. 또한 커널 서버 프로세스가
  요청을 모두 처리한 이후에 클라이언트 프로세스가 다시 실행되도록 해야 한다.
  FCFS 라는 의미 그대로 스케쥴링을 실행하게 된다면, 클라이언트 프로세스가 실행되는 도중에 커널
  서버 프로세스가 실행될 수 없으므로 구현이 불가능하다.
  priority scheduling 또한 사용할 수 있다. 단, 커널이 작동하는 서버 프로세스와 클라이언트
  프로세스의 우선순위에 대해 고려해 볼 필요가 있다. 일반적으로 커널 서버 프로세스는 클라이언트
  프로세스보다 높은 우선순위를 가지도록 설계하는 것이 효율적일 수 있다. 커널 서버 프로세스는
  여러 프로세스가 공유해서 사용하기 때문이다.
  클라이언트 프로세스가 보낸 요청을 커널 서버 프로세스에서 처리하는데 걸리는 시간이 길지
  않다면 문제가 없다. 하지만, 클라이언트의 요청이 커널 서버 프로세스에서 처리되는데 오랜 시간이
  소요되게 된다면, 해당 클라이언트 프로세스보다 우선순위가 높고 커널 서버 프로세스보다
  우선순위가 낮은 다른 클라이언트 프로세스는 실행이 밀리게 된다. 결과적으로, 운영체제는
  우선순위를 설정했으나 우선순위를 고려하지 않은 스케쥴링을 수행하게 된다.
  서버의 우선순위를 미리 정하지 않고, 요청한 클라이언트의 우선순위와 서버 프로세스의 우선순위를
  동일하게 한다면 이러한 상황을 막을 수 있다.

모듈 방식

커널의 핵심적인 부분만 구현하고, 이후에는 운영체제를 실행하면서 동적으로 더 많은 서비스를 제공한다. 런타임 중 커널에 모듈을 삽입할 수 있다.

하이브리드 시스템(맥)

여러 개의 레이어로 나눈다

user experience : 터치 등,,
swift, objective-c등의 프로그래밍 언어에 대한 API
핵심 프레임워크: 그래픽(open gl 등)
커널환경 : 운영체제, Darwin이라고도 불린다.

응용프로그램은 직접 이 모든 기능을 사용할 수 있다.

Darwin의 구조, Mach과 BSD, 두 개의 커널을 가진다.
다른 주소 공간에 존재한다는 단점을 해소하기 위해, 단일주소공간으로 이 모든것들을 결합

윈도우의 리눅스 지원(가상화)

내가 쓰는 bash 커널이 바로 그 예이구나.
linux interface를 제공하고, 리눅스의 어떤 기능을 실행하면, 그걸 윈도우화 해서 바꿔준다.
예를 들어, fork는 window와 linux의 기능이 다른데, fork 명령을 실행하면, 아랫단에서 create_process를 실행하는 등의 역할을 한다.
bash.exe를 실행하면, 리눅스 인스턴스가 생성되고, 프로세스 실행 시 windows의 PICO 프로세스가 커널서비스와 통신하여 기능을 제공한다.

부팅

부트 로더, 부트 스트랩이라고 하는 작은 코드가 커널의 위치를 찾는다.

BIOS(비휘발성 펌웨어)에 부트로더가 존재

컴퓨터를 키면 이 BIOS가 실행된다.

일반적으로, BIOS는 첫 번째 부트로더고, 디스크 블록의 두 번째 부트 로더를 적재하고 실행시킨다.

최근에는 UEFI라고 해서, 부트로더 하나가 모든 거를 정교하게 사용하는 방법이 있다. 이 방법을 사용하면 부팅 시간이 단축되겠네

두 번째 부트로더는, GRUB이라는 게 있는데, 이거 잘 보면 그냥 SHELL같은 느낌.
커널이 메모리에 적재된다.
커널은 하드웨어를 초기화한다.
루트파일시스템이 마운트된다.
리눅스는 그리고, systemmd를 생성한 다음, 다른 서비스를 시작한다.
그리고 로그인 창이 똑

디버깅

프로세스 실패 시 로그파일 저장 및, 코어 덤프(메모리 덤프)
커널의 실패는 크래시라고 함, 로그와 크래시덤프 저장
proc 파일 시스템

프로세스에 관한 정보를 마치 파일처럼 놓은 것프로세스에 관한 정보를 마치 파일처럼 놓은 것

윈도우에서는 작업관리자로 가능
BCC라는 디버깅 툴을 사용할 수 있다.