[OS] 2. 시스템 구조

1. OS service

사용자 인터페이스(UI) : CLI, Batch Interface, GUI
↑↓
System call
↑↓
프로그램 실행	입출력 연산	파일 시스템 조작	통신	오류 탐지	자원 할당	회계	보호/보안
		읽기/쓰기 /생성/삭제 /수정/권한	프로세스 간 정보 교환				시스템 자원에 대한 접근 통제 /외부로부터의 접근 관리

 

 

 

2. System Call

system call

- System call은 Privileged instruction 즉, Kernel mode에서만 사용가능한 Instruction을 호출한다

- 이를 호출하기 위해 User는 OS가 지원하는 User Interface를 통해 요청한다

- System call이 호출되면 User mode에서 Kernel mode로 전환되어 System call에 맞는 요청을 수행한 뒤

다시 User mode로 전환된다

- 이때 대부분의 접근은 High-level interface 즉, API를 활용하여 구현된다

 

 

 

3. OS 디자인

정답은 없지만

실행 환경을 생각하고,

User, System의 Goal을 고려해서 구현되어야 한다

 

또한 기능적으로

1) Policy : 무엇을 해야하는지

2) Mechanism : 어떻게 해야하는지, 즉 policy set을 구현하는 tool

각각을 독립적으로 잘 만들어야 범용성있게 활용 가능

 

 

 

4.  구조 종류

1) Simple structure

- Module로 나누어지지 않음

- No User/Kernel mode : Application이 HW에 접근 가능

- Single tasking/memory space

- System 부팅 시 Shell이 호출

- Process 개념 X

 

2) Layered approach

- 가장 바깥 layer : User <-> 가장 안쪽 layer : HW

- 인접한 layer끼리만 통신 가능, 즉 먼 layer끼리는 중간 layer들을 거쳐야함

- 확장/유지가 간편해짐

 

3) Monolithic

- No layered와 layered의 사이(beyond simple but not fully layered)

 : 표를 보면 인접하지 않은 layer 간에 연결이 있음

- 성능이 매우 좋음

- 유지/보수가 어렵다

- 보안/안정성이 좋지 않다

: OS의 component가 전체를 파괴할 수 있고 전체 OS cod가 하나의 memory space를 위해서 실행되기 때문에

 

4) Micro kernel

Micro kernel

- 최대한 많은 기능을 User-space service로 보낸 것

- 유지/보수/추가/안정성/보안성이 비교적 높다

- 하지만 kernel space와 통신하는 user-space 성능에 overhead가 발생할 수 있다

 

5) Module

- 현재 대부분의 OS 구조

- 동적으로 kernel module을 load한다

 

6) Hybrid system

 

 

 

5. Syetem Boot

CPU와 HW에게 power전달

> CPU는 특정 주소에 있는 Instruction을 실행

: Bootstrap program을 Load하라는 Instruction

> Bootstrap program이 OS를 Load하고 실행

 

ex) Bootstrap program이 BIOS일때

BIOS가 1차 boot loader를, 1차 boot loader가 2차 boot loader를 load

: kernel이 올바르게 시동되기 위해 필요한 모든 관련 작업을 마무리하고 최종적으로 OS를 시동시키기 위한 목적을 가진 프로그램, 하드디스크에 존재한다

> 2차 boot loader가 kernel을 memory에 load

> OS 실행