Separating policy and mechanism
- Policy: 무엇을 할건지(정책) → 리소스 할당 문제에 중요
- Mechanism: 어떻게 할건지(구체적 알고리즘) → 정책을 구현할 도구
policy가 변할 수 있기 때문에 호환성(유연성)을 가져야함 → mechanism과 policy를 분리해야함
- ex) 운전 시스템: 안전 주행 보조
- Policy: 전방 추돌 방지을 위한 특정 알고리즘
- Mechanism: 브레이크 & 가속
→ mechanism이 특정 알고리즘에 종속되어있지 않고 잘 분리되어있다면 policy의 알고리즘이 바뀌어도 ㄱㅊ음
- ex) CPU schedular: CPU 큐에 일 할당하고 싶음
- Policy: scheduling algorithm(FIFO, SJF, priority…)
- Mechanism: CPU dispatcher(스케줄링 결과에 따라 CPU에게 특정 일 할당)
Implementation
다양한 언어로 운영체제가 작성된다
- 초반에는 어셈블리어, 요즘은 호완성을 위해 c, c++
- 다양한 언어가 섞이기도 함(예를 들어, low level 컨트롤을 위해 일부는 어셈블리로 작동하고, 메인은 C)
- high-level 언어로 작성하면 구현이 쉽지만 느리고 성능이 낮아짐..
Structure
일반적으로 OS는 아주 큰 프로그램이다. 커널은 PC가 작동 중일 때 항상 메모리에 로드되기 때문에 성능에 큰 영향을 미친다.
다양한 형태의 OS가 존재한다.
simple structure(MS-DOS)
- 초기, 간단 → 모듈로 나눠지지 않고, OS전체가 한 덩어리
- single tasking, single user
- Shell(command interpreter)로 동작
- 프로그램을 시작하면 shell범위를 줄이고 프로세스를 올려서 동작
Monolothic(Unix)
- 직관적, 단일 체제 OS
- 단일 체제 → 단일 메모리 공유 → 모듈 간 공유가 빠름, 부담 적음 → 성능 좋음
- policy/mechanism분리 불가능 → 유연성 떨어짐
- 드라이버의 오류가 전체 시스템의 오류로 이어질 수 있음, 중요하지 않은 부분이 오류나면 좀..
- 업데이트가 어려움(업데이트 할 때마다 시스템 유지가 안되고 새로 까는 느낌) → 확장성 나쁨
layered structure(Abstraction-based)
- 계층별 체제로 위의 단점 보완
- 인접 커널과만 상호작용 가능
- 특정 부분의 오류 시 해결 및 업데이트가 쉬움
- 통신 layer에 사용
Microkernel(Mach)
- 커널을 작게하여 진짜 필요한 것 빼고 나머지는 유저 모드로
- 핵심 커널이 작고 abstruction이 잘 되어있어서 대부분의 하드웨어에 쉽게 올라갈 수 있음
- 여러 기능을 여러 모듈로 분리하여 관리 → 유연성, 안정성
- system call을 쓸 수 없고, message passing 사용 → 성능 떨어짐
Monolithic vs Microkernel
리눅스, 윈도우는 결국 mono로 갔다..
개발자가 힘들고 성능 좋은게 짱이다~
Module
- 모듈별로 프로그램을 OS에 쉽게 붙일 수 있음 (모듈화, OOP 개념)
- layered, microkernel과 비슷
- 인접 커널과만 상호작용 하던 layered보단 자유도가 높다
- 모듈이 커널에 들어가면 소프트웨어에 종속되도록해서(메모리 영역을 공유하도록해서) microkernel처럼 message passing을 사용하지 않아도 됨
Hybrid
- 이게 현실
- 다양한 방식이 함께 사용된다~~
( •̀ .̫ •́ )✧