OS Services
- OS는 프로그램의 수행을 위한 환경 제공, 프로그램과 프로그램의 User에게 특정 Service를 제공 ⇒ interface를 통해
- OS에서 제공하는 Services 다양하고, Application이 OS의 Service를 이용하기 위해서는 System call을 거쳐야만 가능
OS Services for User Support
User interface
- CLI(Command-Line Interface): 리눅스 개발환경, cmd → GUI보다 빠르고 강력
- GUI(Graphic-User Interface)
- batch interface: 명령어들의 sequence를 실행
Program Execution
- 메모리에 load, run and end execution
I/O operations
- device가 PC에 연결되도록 allow
File-system manipulation (I/O operation의 일종)
- 프로그램이 직접적으로 접근하는 것 X, OS를 거쳐서 이때 System call이 필요
Communications (= Networking) → 프로그램 간 또는 Computer 간
- MSG를 전달하는 방식
- 직접 전달하는 방식인 msg passing → Connection이 필요
- 공유된 memory를 이용하여 전달하는 방식인 shared memory → Connection이 필요 X, sharing을 위해서 System call이 반드시 필요, msg 전달에 있어 delay 발생
Error Detection
- HW-Level의 error와 SW-Level의 error 존재
- memory error, Power failure, parity, connection failure, ...
- bit flip
- Bit 반전, 프로그램 수행 중, 데이터의 bit가 원치않게 flip될 수 있음
- 감지가 어려운 error: silent error
- memory leak: 어떤 프로그램이 memory를 계속 조금씩 조금씩 차지 ⇒ 나중에는 메모리가 남지 않게 됨.
- 이때, 종료한 후 다시 실행하면 해결되지만 종료할 수 없는 서버의 경우는 문제
- memory leak: 어떤 프로그램이 memory를 계속 조금씩 조금씩 차지 ⇒ 나중에는 메모리가 남지 않게 됨.
OS Services for Efficient Operation
- User에게 보여지지 않음
Resource Allocation: resource 할당 해결
Resource Accounting
- 어떤 프로세스가 resource를 얼마나 사용하는지 추적
- 너무 많이 사용하는 프로세스에서 resource를 분배, 관리
Protection and Security
- Multi user 환경에서 여러 프로그램들이 resource에 접근 → 이에 대한 Control이 필요
- 서로 다른 프로세스에 대한 간섭, 방해를 막아야 함 → Isolation이 해결책
⇒ "A system is as strong as its weakest link"
아무리 보안성이 좋아도 하나의 약한 부분으로 인해 약해진다 → balanced security의 중요성
System Calls
- library화 되어있음 (package화)
System call : OS kernel이 제공하는 서비스에 Application이 접근하기 위해 사용하는 interface
file copy의 예 ⇒ 많은 system call이 필요
- copy를 위해서 OS는 목적 파일 이름과 원본 파일 이름을 요구
- 파일이 없거나, 파일에 대한 권한이 없는 경우, error 발생하고 그렇지 않으면 copy할 준비
- read와 write가 반복적 수행 → copy 프로그램이 수행
- 완료 시, 두 파일을 close하고 완료 msg를 return
⇒ OS가 모든 일을 수행하고, User는 App를 이용하여 OS에 request
Simple task에도 system call은 사용됨
프로그래머들은 API (=set of functions)를 통해 간접적으로 system call 호출
-
Windows API, POSIX API, Java API
-
Java API는 다른 API와는 다르게 상위 계층에 존재
JAVA API → libc → system call 관계
- 하나의 libc function이 하나 이상의 system call을 호출할 수도 있고,
- 하나의 system call이 하나 이상의 libc function으로부터 호출될 수도 있다.
- 모든 libc functions이 system call을 호출하는 것은 아님
- Why use APIs rather than System Calls directly?
- 인자나 buffering 문제 해결이 어렵기 때문에 직접적으로 호출하지 않음
- Portablity문제(code를 다른 환경(system call setup이 다른 = different mapping)에서 compile가능 = portable)
- libc는 system call을 사용하기 위해 필요한 인자를 채워주는 역할
System Call Interface
Set of library functions that links to the system calls
- user application에서 libc 호출
→ system call interface를 통해 kernel mode로 접근
→ OS에 정의된 system call을 실행하고 return되는 int값을 가지고 다시 user mode로 switch
→ user application에 값 return
int main() {
...
...
f1();
f2();
# regular function -> 함수 선언이 프로그램 내에 존재.
}
int f1() {
...
...
open();
# system call -> 함수 선언이 kernel space, 즉 OS에 존재 => CPU가 처리방법을 define
}-
regular function의 경우
- 실행 위치만 옮겨서 해당 function을 수행
-
System call의 경우
- user mode → kernel mode로 switch한 후, 해당 요청 처리하고 다시 mode switch하고 return value
⇒ mode switching이 시간을 소모
- eax ← system call #
- ebx ← fd
- ecx ← flag
- edx ← count
- 해당 레지스터 값을 채운 뒤 system call 호출 ⇒ libc function이 수행
System Call Types
Process Control
- fork, exec, exit, ...
File manipulation
- create, open, close, read, write, lseek
Device manipulation
- open, close, read, write, ioctl
Information maintenance
- time, date, pid
Communications
- open, close, connect, accept, read, write, send, recv, pipe, ...
Protection
- Chmod, umask, chown, ...
⇒ open, close, read, write → 같은 object로 취급하여 모두 사용 가능 (리눅스는 모두 file로 취급)
System Call Types: Process Control
- program file → execute → process (state를 가짐 ⇒ control이 가능)
Error handling
- 종료 → memory dump를 생성 → msg 출력 → 다음 명령어 수행
Loading and executing another Program
- 새로운 프로세스가 종료된 후 프로그램 흐름을 어디로 return 해야 할 지
- 동시에 실행할 지 않을지
System Call Types: Communications
- Communication -> IPC
Message Passing(Synchronous)
- Connection이 가장 먼저 open되어야 함 → 서로 준비되어야 함
- Connection 생성에도 system call이 필요
Shared-Memory model(Asynchronous)
- memory에 msg를 저장, msg를 pick-up하는 형태 → 의사소통에 delay가 발생
- Connection이 필요 X
- Sharing을 위한 system call이 무조건 필요, shared memory 지역에서의 integrity of data를 조심
OS Design and Implementation
Design goal
- User goals : 쉽고 신뢰성 있고, 빨라야 함
- System goals : 개발의 용이, 유지 보수의 용이, ... ⇒ OS가 모두 만족하기 어려움
⇒ 막연한 요구사항과 명확하지 못한 해결책
Guideline: Mechanism and Policy
- 메커니즘과 정책을 분리
- 메커니즘 : 어떤 일을 어떻게 할 것인가를 결정하는 일
- 정책 : 무엇을 할 것인가를 결정하는 일
- 분리하는 이유
- 정책은 장소가 바뀌거나 시간의 흐름에 따라 변경될 수 있는데, 정책의 변경이 메커니즘의 변경을 요구하는 경우 그렇지 않은 경우보다 바람직하지 못함
OS Implementation
- assembly 언어로 구현 → 오류 발생 ↑, 어려움, port 어려움
- 고수준의 언어로 구현 (C, ...)
- 장점
- 구현 시간이 빠르다
- 간결하고 이해와 디버깅이 쉽다
- 컴파일러의 발전이 코드 생성을 향상시킬 것
- 단점
- 성능: 항상 차선의 코드 생성
- 고수준의 언어로 쓰인 small critical code가 나중에는 다른 최적의 코드로 대체
- 장점
Operating System Structure
Monolithic structure vs. componentized, modularied approach
-
monolithic structure
- 간단한 동작
- 하나의 큰 조각, 서로 의존 ⇒ 하나를 변경하거나 대체하기 어려운 문제
⇒ 확장성이 좋지 않다
- kernel에 여러 기능들이 합쳐져서 존재 (tightly coupled)
OS Structure: Layered Approach
Layered approach
- Layer 0: HW, Layer M: user interface
- 각 Layer는 오직 상위 또는 하위 1개의 계층과만 소통 가능
- Layer M은 Layer M-1의 operation을 유발 (request)
- Layer M-1은 Layer M에게 요청받은 서비스 제공 (response)
- 장점
- 간단한 구조 ⇒ 디버그의 용이
- 층이 분리되어 있으므로 Layer가 대체되어도 interface는 변경 X
- Layer 1 → Layer 1`로 변경, Layer 2가 Layer 1에 요구한 요청에 대한 reponse가 틀린 경우, Layer 1만 Debug하면 완료
- 단점
- Layer를 정의하는 것 자체가 어려움 (functionality 사이의 충돌)
- Layer를 오가는 것이 많은 overhead를 발생시킴
- function call로 인한 계층 이동 → mode change가 포함될 수 있음
- Layer 수의 증가 ⇒ 실행 시간의 증가
Microkernels
- 그저 approach 중 하나일뿐 현재 사용하는 이론은 아님
idea
- 중요한 기능만 kernel에 remain
- 나머지는 user-level에 위치 → kernel의 크기 감소 ⇒ mode switch를 줄임
장점
- OS kernel의 확정성 증가
- kernel의 크기가 작아지므로 port가 용이
- 안전하고 신뢰성 증가 (작은 게 더 안전, smaller attack surface)
단점
-
성능 저하
- message passing 방식으로 인한 overhead가 발생
- App의 Request를 받아서 user model에 있는 function으로 redirect, 이때 msg 전달
배우고 정리하고 공유하기