[운영체제 공룡책] Ch 2. Operating-System Structures

📍 공룡책 기반으로 학교에서 수업했던 운영체제를 정리합니다.

0️⃣ Introduction

What Operating Systems Do?

• 운영체제 = 컴퓨터의 사용자와 하드웨어 사이에서 중개 역할을 해주는 것
• 커널 = 보통 리눅스의 OS를 부르는 것. 알맹이. OS의 가장 핵심적인 부분

---

How Operating Systems Interact?

User ↔ Program ↔ OS ↔ Hardware

• OS와 프로그램 사이에 interaction이 존재하고, OS와 하드웨어 사이 interaction이 존재
• OS와 하드웨어 사이 interaction에 대한 interface = Interrupt

---

Computer System Organization

• system bus = 통신하는 ‘통로’
• 외부 디바이스 → device controller를 통해서 연결.
  • device controller는 device type에 따라서 존재.
  • device controller는 마더보드에 내장되어있다. (system bus도 마더보드 위에 내장)
  • 전자 회로로 구성되어있는 ‘하드웨어’에 해당
• OS는 device controller과 소통하기 위해서 device driver라는 SW 단의 것을 갖고 있다

device controller, system bus는 hardware 단이고, device driver는 software단!!

---

1️⃣ Interrupts

What Interrupt is

당신이 이 그림을 이해했다면 아래 글을 읽지 않아도 좋다

 

❗️ 인터럽트를 발생시키는 주체 = device controller

ex) 키보드 누름(입력)

→ 키보드 device controller가 system bus를 통해 CPU에 인터럽트 신호를 보낸다

→ CPU가 detection하고 원래 작업 중단하고 interrupt handling 시작

→ interrupt handling이 끝나면 원래 작업 다시 재개

 

❗️ 인터럽트 processing은 OS 안에서 일어난다.

• 인터럽트가 발생하면 Interrupt Vector라는 인터럽트 Type에 대한 정보가 담겨 있는 데이터 스트럭쳐를 읽고, 그 타입(ex: 키보드, 마우스, … )을 먼저 파악한다.
  • interrupt 벡터가 타입에 맞게 함수에 대한 포인터를 갖고 있다.
  • 이 함수는 메모리 위에 올라가있는데, 부팅을 하게 되면 OS가 initialize를 해줘서 메모리의 정해진 부분에 들어가있게 되고, CPU는 인터럽트가 발생했을 때 이 부분을 읽어야 한다고 이미 알고 있게 된다.

• 타입에 맞는 Interrupt handler를 호출한다.
  • interrupt handler = interrupt service routine = 인터럽트를 처리하는 함수

❗️ 인터럽트 처리 시간 동안 CPU는 기다리지 않고 유저 프로그램을 실행한다!

ex) 디스크에서 데이터를 읽고 싶다고 했을 때, 디바이스(디스크)에 요청하면 거기에서 처리하는 데 시간이 걸린다. 그 처리 시간 동안은 다른 작업을 하는 게 효율적이다.

→ I/O 요청을 보내고 디바이스(디스크)가 작업을 끝내면 디스크가 Interrupt를 줘서 작업이 끝났다는 것을 알려준다!

 

❗️ 인터럽트라는 것은 수시로 발생할 수 있기 때문에, 인터럽트 핸들링하는 시간이 매우 짧아야 한다.!

• 시간이 길어지면 유저 프로그램을 실행시킬 시간이 없다.

---

Implementation

❗️ 하드웨어

• 컨트롤러에서 바로 들어오는 것이 아니라, PIC라는 인터럽트를 위한 컨트롤러가 또 존재(Programmable Interrupt Controller)
• 다양한 디바이스에서 여러가지 타입의 인터럽트가 들어오면 다 합쳐주는 역할
  • 여러 곳에서 동시에 발생할 수도 있기 때문에 구분 및 조율해서 CPU에게 전달해주기 위해 필요
  • 시그널이 들어오면 CPU가 정해진 동작(인터럽트 벡터를 읽어서 …) 하도록 프로그램 되어있다
  • → CPU에서 전기적 signal을 받는 포트(핀)= Interrupt Request Line
• 마더보드의 southbridge chip에 위치한다

📍 마더보드의 구성

- North Bridge : GPU(그래픽스) 통신, RAM(메모리)

- South Bridge : 나머지 디바이스 (USB, I/O ...)

- CPU

- GPU

 

📍PIC → external Device 연결 → South Bridge

 

❗️ 소프트웨어

Types

OS에서 구분하는 인터럽트 타입에는 2가지가 있다.

(1) 하드웨어 인터럽트

• 하드웨어 디바이스에서 실제 발생한 전기적 신호를 받는 것

(2) 소프트웨어 인터럽트

• 하드웨어 인터럽트와 헷갈려서, exception이라고 부르기도 한다
• 외부 디바이스에서 오는 게 아니라, 프로세스 자체에서 들어오는(프로세스 자체가 request하는) 인터럽트
  • ex) 잘못된 메모리에 접근 → 시스템 내부에서 “Segmentation Fault” 발생

---

2️⃣ System Calls

What System Call is

• System call = 유저 프로그램에서 OS가 제공하는 서비스를 이용할 수 있는 인터페이스(API)

---

 

• 예시) 파일을 열고, 파일의 내용을 읽어서, 다른 파일에 쓰는 프로그램을 작성한다고 해보자
  • 파일을 OS가 관리하기 때문에 파일을 여는 것부터 다 시스템콜을 통해서 “내가 파일을 열겠다”고 알려줘야 한다
    • 유저 프로세스가 실행하고 있다가 시스템콜을 호출
    • 유저 프로세스에서 돌아가고 있던 프로그램의 컨트롤이 커널로 넘어간다 (커널의 리소스를 사용하는 것이기 때문에 커널 모드로 전환)
    • 파일을 여는 것 같은 동작 요청의 처리를 커널 단위(level)에서 해준다. (유저 프로그램은 내가 파일을 열겠다고 요청만 하고 실제 처리는 커널에서)
    • 파일 여는 작업이 끝나면 다시 유저 모드로 돌아가서 시스템콜 값을 이용해서 계속 처리를 이어나간다.

---

• 실제 사용 → C/C++ Standard Library 통해서

• 라이브러리 헤더 파일(stdio.h, unistd.h)의 함수(printf(), write()) 구현을 뜯어보면 시스템콜 발생이 포함되어있다. BUT 우리는 시스템콜을 부르는지 알 필요없고, 동작만 알면 된다.
  • → 시스템콜을 직접 부를 일은 없고 API를 통해서 시스템콜을 호출한다

 

---

Implementation

• 시스템콜도 인터럽트와 마찬가지로 type마다 ‘번호’가 부여되어있다.
  • write(), read(), … 등등 다양한 종류의 시스템콜 존재
  • 번호에 따라서 시스템콜 function이 OS에 저장되어있다.
  • 시스템콜이 요청되었을 때 맞는 함수를 호출하도록 되어있다.
    • → system call interface 통해서 시스템콜을 부르고, 리턴값도 넘겨준다
• 실제 리눅스 오픈소스 시스템콜 테이블
  • 시스템콜 number | type | 이름 | 실제로 불리는 함수
    • read system call request → TBL → sys_read() 호출해서 OS가 handling

 

• ex) 프로그램을 작성해서 fopen() 같은 함수 호출한 경우

1. 유저 코드의 함수 내에서 open 시스템콜을 보낸다
2. 이를 커널이 받은 다음에 open() 이라는 시스템콜이 발생했을 때 어떤 함수를 불러야할지 알기 위해서, 시스템콜 테이블을 살펴서 맞는 함수를 찾는다
3. sys_open()이라는 함수를 불러서 핸들링을 한 다음 결과값을 유저에게 전달한다

---

Parameter Passing

• read()를 살펴보면 시스템콜에도 파라미터가 존재한다.
  • int fd : 열고 싶은 파일의 file descriptor
  • void *buf : 데이터를 읽어들일 때 필요한, 할당된 버퍼
  • size_t count : 얼마만큼 파일에서 읽어들일 것인지
  → 이걸 어떻게 OS에게 전달해줄까?

❗️ Simplest

• 가장 간단한 방법! =  임시로 사용하는 용도인 CPU의 레지스터에 파라미터 값을 하나하나 저장해둔다
• 첫 번째 eax라는 이름의 레지스터에 파라미터를 넣어놓는다고 OS에서 약속을 해두면, 정해진 레지스터에서 읽어와서 사용하면 된다.
• 단점 → CPU마다 레지스터의 개수가 정해져있다. 파라미터를 무한정으로 넣을 순 없고, 사용할 수 있는 레지스터의 개수만큼만 넘길 수 있다.
• 하지만 제일 간단하기 때문에 현재 리눅스에서 사용하는 방식!!! 무한정으로 사용하고 싶다면 나머지 두 방식 사용

❗️ Block

• 메인 메모리에 저장을 하고, 시작 메모리 주소를 전달해준다.
  • 이 파라미터를 여기서부터 읽어라~ ( e.g - read()에서 읽을 버퍼의 포인터 값을 주게 된다)

❗️Stack

• 메인 메모리에 push를 해놓고 꺼내 쓰기를 하는 방식

---

3️⃣ Operating System Structure

❕ Simple(MS-DOS) ↔ Complex(UNIX)
Layered(abstraction) ↔ Microkernel(Mach)

 

Monolithic Structure - Original UNIX

• 커널이 한 덩어리로 돼있다. 단순한 구조 = 모든 커널의 functionality가 하나의 큰 binary 파일로 묶여 있다.
  
  • file / storage management 등이 다 하나의 커널로 묶여있기 때문에 tightly coupled(굉장히 긴밀하게 연결되어있다)
  • (장점) 한 덩이로 돼있어서 시스템콜을 불렀을 때 모든 서비스에 바로 접근 가능하므로 오버헤드가 적다 (커널과의 소통이 쉽다)
  • (단점) 어떤 한 부분 바꾸게 되면, 다른 부분에도 영향을 줄 수 있다는 문제

---

Layered Approach

monolithic(모두가 서로 접근 가능) ↔ Layered(위에서 아래로만 접근 가능)

• OS에도 단계(layer)가 있다.
  • 내려갈수록 낮아진다. → 0번은 하드웨어. 가장 바깥쪽은 유저 인터페이스
  • 권한에 따라서 레이어를 나눠놓고, 위→아래로만 접근 가능
  • 장점
    1. 직관적 구조 → 나눠놓고 각 레이어에 맞게 모듈 구현 → 디자인 쉽다                                                                                  (컴네의 TCP 레이어 같이 하드웨어적으로 구분이 되는 경우에는 디자인이 쉽다)
    2. 디버깅, verification 쉽다 → 레이어 단위로 하면 되니까                                                                                        (monolithic은 다 tightly coupled라서 잘못하면 다른 데도 영향 줄 수 있음)
  • 단점 : 성능이 안 좋을 수 있다
    • layer1을 접근하려면 상위 layer를 모두 거쳐야 한다 → 시스템 서비스에 접근하는 시간이 더 오래 걸린다.

---

Microkernels

• 커널이 하는 것을 유저 스페이스로 끌어올렸다.

• 커뮤니케이션 방식 → Message Passing
  • file system이 device driver랑 소통해야할 일이 있을 때 메세지 패싱 방식으로 소통
  • 커널이 관리를 해주는 메세지를 전달.
• 장점 : 커널이 단순해진다. extension하기 쉽다. reliable하다.                                                                                                       → 커널 모드에서 애초에 돌아가는게 적어서, 데이터 유출될 확률이 적다
• 단점 : 메세지 패싱 방식을 이용한 유서 스페이스에서 커뮤니케이션이 퍼포먼스 오버헤드가 있다