OS 아키텍처(1)✨

‍서지오·2024년 1월 25일

목록 보기

2/3

이 글을 한국외국어대학교 이윤석 교수님의 운영체제 수업을 스스로 복기하고자 작성한 글 입니다.

IO operation

IO : device controller buffer와 장치(device) 사이에 데이터를 주고 받는 작업
- Writing to Device : main memroy ⇒ controller’s buffer
- Reading from Device : controller’s buffer ⇒ main memroy
IO와 CPU는 동시에 수행될 수 있어야 한다.
일반적으로 장치 하나 당 device controller가 하나씩 존재하지만 하나의 device controller가 여러 개의 장치를 관리하는 경우도 존재한다.
Device Driver : 모든 device controller를 제어하기 위한 SW
- OS는 내부 로직을 모른 채 device를 하나의 파일이라고 생각하고 사용하고 device driver가 device에 맞게 동작하도록 한다.

Memory Mapped IO
- IO 장치를 위한 Memory Address Space를 둔다.
- memory access와 IO access가 일관된 형태를 지닌다.
  - load, store 명령어를 io할 때도 사용
- 일반적으로 사용되는 방법이다.
Special(isolated) IO
- IO를 위한 bus가 필요(별도의 HW 필요)
- IO를 위한 명령어가 필요
  - IO작업과 메모리 작업이 구분이 쉽다.
- memory address space가 필요하지 않아 memory address space가 작은 장치에서는 유용하다.

Cpu가 IO 작업에 전체적으로 개입하는 IO
모든 IO 작업에 cpu 명령이 필요함
cpu가 IO작업 상태를 계속해서 체크한다. (Polling)
- 비효율적이다.
- cpu가 많은 시간을 device를 checking하는 데 사용된다.
- polling IO의 단점을 개선하기 위해 Interrupts가 등장
  - os와 hardware는 서로 feed back 하면 진화하였다.
Device controller가 지녀야 할 것들
- Data-in register : 장치에 입력을 데이터를 저장할 공간
- Data-out : 장치로 내보낼 데이터를 저장할 공간
- Status register : 현재 장치의 상태를 표현하는 레지스터
- Control register : 장치에 보낼 command(명령어)들을 저장할 공간
handshaking 과정 교재 확인(p.7)

Cpu hardware는 interrupt-request line을 지녀 interrupt가 왔는지 안왔는지를 체크한다.
하나의 명령어를 수행 후 다음 명령를 수행하기 전 interrupt request line을 확인하여 interrupt 유무를 체크한다. (명령어와 명령어 사이에 interrupt 확인)
동작 과정
1. 현재 context(작업상황)를 저장
  1. cpu안의 register 상태
2. interrupt handler로 분기(메모리 어딘가에 존재)
3. 다시 작업 재게
Device controller는 interrupt를 일으키고(raise) CPU는 이를 catch하고 interrupt handler가 dispatch(실행) 및 clear된다.
일반적으로 OS는 interrupt-driven software이다.
- HW : sends trigger on bus
- SW : use system call

현재 cpu 상태(register값)를 저장
- 저장 방법
  1. 고정된 위치
  2. 장치마다 다른 위치
  3. 시스템 스택 영역
장치 식별
- Interrupt Polling : 장치들이 하나의 interrupt request line을 사용, cpu가 interrupt가 오면 request line을 쭉 따라가며 장치들을 돌면서 어디서 interrupt를 보냈는지 확인해야 했다.
- Vectored Interrupt System : interrupt를 보낼 때 장치 번호를 함께 보냄 ⇒ handling할 때 바로 장치로 분기가 가능하다.

CPU가 개입하지 않고 Device controller와 Memory간 데이터를 전송할 수 있도록 하는 기술
바이트 단위로 데이터를 interrupt를 발생시키는 게 아니라 지정한 block만큼 데이터가 전송 되면 그 때 서야 interrupt를 한 번만 보냄
interrupt handling 과정은 비용이 꽤 드는 작업인데 이러한 Interrupt가 너무 자주 일어 났을 때를 위해 고안된 방법
대용량 데이터를 전달할 때 혹은 고속 IO 장치에서 주로 사용

Interrupt를 지연 또는 아예 안 받을 수 있음
- 중요한 작업 중이라 방해 받고 싶지 않을 경우 사용한다.
Interrupt를 보내는 장치마다 우선순위(priority)를 둔다.
- multi level interrupt handling
- 낮은 인터럽트 처리 중 높은 인터럽트가 발생한다면 이를 중단하고 높은 인터럽트를 먼저 처리한다.
Interrupt Vector 사용
- IVT(Interrupt Vector Table) : 각 장치의 Interrupt Handler의 주소를 저장한 테이블
- IVT를 통해 interrupt를 보낸 장치의 interrupt handler를 즉시 호출 가능하게 한다.
cpu는 두 가지 interrupt request line을 지닌다.
- Maskable interrupts : 끌 수 있는 line
- Non-maskable interrupts : 끌 수 없는 line, 끄게 되면 심각한 에러가 발생하는 경우 사용

Trap : 유저 프로그램이 OS 서비스를 받기 위해 의도적으로 수행하는 명령
- system call에 의해 발생
- software의 interrupt이다.
Exception : 비정상적인 상황에 발생
- 오류 상황에 발생
공통점
- 실행 중인 프로세스를 중단
- handler routine 호출
- 처리 후 이전 상태로 돌아가 프로세스 재게

OS가 비정상적인 상황을 막기 위해 제공하는 것
Protecting Memory
- 각 프로세스가 자신에게 할당한 메모리만 사용하도록 하는 protection
- 현대 운영체제는 각각의 프로세스를 독립적으로 구분한다.(서로 간 개입이 불가능)
- base register와 limit register를 둬서 영역 내 address에 접근했는지를 확인
- 초창기 방법이다.
CPU control
- 프로세스가 cpu를 올바르게 사용하도록 하는 protection
- Cooperative : 프로세스들이 cpu를 올바르게 나눠서 사용하는 경우를 의미
- 특정 프로세스가 의도치 않게 무한 루프에 빠져 cpu를 독점하게 되는 경우가 발생 ⇒ 이를 위해 Timer 등장
Timer Hardware
- 특정 주기(quantum, slice) 마다 interrupt를 보내도록 하여 Interrupt Handler가 동작하도록 한다. ⇒ OS에게 제어권을 넘김
- counter variable을 둬서 interrupt의 발생 횟수를 지정할 수 있다.
- timer에 시간을 지정하는 명령은 protected(previleged) 명령이라고 부른다.