해당 글은
경희대학교 조진성, 허선영 교수님의 강의 자료 및 내용을 정리한 글입니다
개인적으로 공부하며 작성된 글이라 잘못된 부분이 있을 수 있습니다!
오류가 있다면 알려주세요
OS는 User와 Hardware 사이의 중간자 역할!
User → OS → Hardware의 구체적인 상호작용이 어떻게 이루어질까?
Computer System Organization
▶Device Controller
- device type에 따라서 device controller는 달라짐
- OS는 각 device controller마다 해당하는 device driver를 가짐
- Shared memory에 접근하기 위해 연결된 Common bus
Interrupts
- OS-Hardware는 Interrupts를 통해 상호작용함!
- Device controller는 CPU에게 자신의 operation이 끝났음을 알리기 위해서 Interrupt를 일으킴
- Interrupt의 종류가 무엇인지에 따라서, Interrupt vector에 따라 handler가 호출됨
- I/O request: CPU에서 device에게 요청을 보냄
- I/O device는 받은 요청을 처리함 ex) 데이터 전달, 프린트 ...
- I/O device는 작업을 끝내고, 이를 CPU에게 알림 →→ Interrupt!
- CPU는 실행하던 program은 중단하고, Interrupt Handling 수행
▶Interrupt Vector
- OS는 Interrupt vector를 읽고, 해당 type에 맞는 handler를 부르게 됩니다
- Interrupt vector은 int와, 그에 대응하는 함수에 대한 포인터가 존재함
- OS가 booting될 때 초기화를 진행하므로 해당 데이터는 미리 메모리에 올라감
▶Implementation
Hardware
- 여러가지 Type의 Interrupt가 있을 때, 종합하는 역할을 Programmable Interrupt controller가 수행
- 종합한 interrupt는 CPU 단에 넘어감 (Interrupt Request Line)
↓ Programmable Interrupt Controller (PIC) 이란? ↓
더보기
일반적으로 PIC는 motherboard의 southbridge에 내장됨
Software
- Device driver를 초기화함
- I/O Controller 또한 초기화
- 요청받은 작업을 수행하고, Interrupt Signal을 OS로 보냄
- Interrupt를 받은 CPU는 Handler에 따라서 처리할 수 있음
- 해당 통제권은 Interrupt handler에게 PC에 지정함으로서!
- Interrupt가 끝나면, 이전에 수행하던 프로그램을 다시 이어서 처리함
▶Types
- Hardware
- 외부 하드워드 이벤트에 대응하여 발생
- Interrupt request(IRQ)에 의해 시그널링됨
- Software(Exceptions)
- 특정 명령을 실행할 때 프로세스 자체에서 요청함
- ex) fault, traps, aborts
System Call
- OS-Program은 System Call을 통해 상호작용함!
- User program 단에서 다양한 서비스를 이용할 수 있도록 하는 것
▶ User/Kernel mode
- System call은 User mode에서 API를 통해서 호출됨
- 실질적인 역할을 수행할 때는, Kernel Mode로 전환됨
- Application Programming Interface(API) - ex) Win32, POSIX, JVM ...
- printf() library call →→ write() system call
▶ Implementation
- System-call interface
- 각 System call 마다 number가 부여되어 있고, 그에 따른 function이 대응되어 있음
- 호출자는 system call이 어떻게 구현되는지 알 필요 없음!
Parameter Passing
- System call이 수행하는 기능에 따라, 필요한 데이터가 다름
- 이때 전달해야하는 parameter은 Kernel에게 전달하므로, Stack에 저장할 수 없다는 문제
- Register: CPU내의 register에 parameter 값을 저장함. 매개변수 갯수의 한계 존재
- Block: 메모리에 저장해둔 뒤, 메모리의 주소를 넘김
- Stack: 메모리에 Push해둔 뒤, Pop하여 쓰는 방식 How?
▶Types
- Process Control: fork(), exit(), wait()
- File Management: open(), read(), write() ...
- Device managment: ioctl(), read() ...
- Information mainrenance: getpid(), alarm(), sleep() ...
- Communications: pipe(), shm_open(), mmap() ...
- Protection: chmod(), umask() ...
OS Structure
OS 는 갱장히 큰 프로그램임!
Simple structure
- MS-DOS
- 계층에 대한 구분이 없음
- User program이 입출력 루틴에 접근하여 직접 write 가능
- 👎🏼 User program이 전체 시스템에 영향을 미칠 수 있음
Monolithic Structure
- 전통적인 Unix 시스템 구조
- Kernel이 하나의 큰 binary file로 묶여 있고, OS의 모든 기능을 제공
- 따라서 System program / kernel의 2가지 part로 구성됨
- 👍🏼 System-call interface로 Kernel에 접근이 쉬워서 오버헤드가 작음
- 👎🏼 시스템이 긴밀하게 묶여있어 유지 보수가 어려움
- 따라서 더 모듈화시킨 것이 Linux
Layered Approach
- Layer 개념을 사용하여, 각 layer에 권한을 부여해서 아래로만 접근 가능하도록
- Bottom: Hardware, Highest: User interface
- network, web application에서 활용 굿
- 👍🏼 직관적인 구조, layer 단위로 디버깅이 가능해짐
- 👎🏼 Layer단을 전부 거쳐야하다 보니 상대적으로 performance가 떨어질 수도
MicroKernels
- kernel에서 핵심적인 요소만을 남기고, 나머지 기능은 Application process로 구현한 형태
- ex) Mach
- Unix의 경우 kernel의 역할이 큰 편인데,
- 이 기능을 일부 User space로 끌어올린 형태
- Message Passing: kernel이 관리하며 User Space와 커뮤니케이션 수행함
- 👍🏼 kernel이 단순해져서 확장이 쉬움. 데이터 유출 확률이 적음→ 안전하네
- 👎🏼 User space와 Kernel Space 간의 커뮤니케이션에서 Performance Overhead 발생 가능
'STUDY > 운영체제' 카테고리의 다른 글
| [OS] Chap06. Synchronization Tools (0) | 2023.10.16 |
|---|---|
| [OS] Chap05. CPU Scheduling (0) | 2023.10.10 |
| [OS] Chap04. Thread & Concurrency (0) | 2023.10.10 |
| [OS] Chap03. Processes (0) | 2023.10.05 |
| [OS] Chap01. Introduction (0) | 2023.10.05 |
