운영체제가 user에게 제공하는 interface가 2개 있음
- CLI
쉘 , 터미널 - desktop metaphor interface,
마우스 기반 윈도우 인터페이스
System call, API
os 위에 middleware 존재 , 이 미들웨어가 제공하는 인터페이스가 API,
개발자는 미들웨어가 제공하는 API로 프로그램을 만듬
앱제작 시 system call 보다 API를 사용하는 이유
- OS가 달라도 같은 api를 제공하는 시스템에서 앱이 동작될 것을 기대
모노리딕 구조
layered Operating System
- layer를 하나씩 거쳐가야함, 건너 뛰어서는 안됨
상위 계층이 하위 계층을 함수 호출 => down call,
일반적으로 그 반대인 up call을 호출해서는 안됨. - 장단점
- 장: 디버깅과 만들기 쉬움
- 단:
- 레이어 나누기 어려움
- 레이어의 정의가 모호함으로 의존성이 깨질 수 있음
- 계층이 많아질 수록 부하가 커짐
- 레이어 추가시 안정화가 무너질 수 있음 -> 보완하기 위해 Microkernel
- 레이어 어프로치를 통해 down call만 하도록 지향해야함,
같은 레이어는 양방향 호출 가능
ex) ms-dos
Unix system structure
microKernel sys sturcture
커널모드(microkernel)에
1. process management
2. memory management
3. synchronized
4. ipc
이외에 network, file 등은 user mode에서 독립적인 프로세스로 돌아감
앱이 파일 시스템의 어떤 서비스 open, read, write등을 받고싶으면 ,
앱과 파일 서버가 통신을 통해 요청을 보내고 응답을 받음, 이때 ipc를 사용(대표적 msq)
그러나 윈도우가 업데이트 되면서 다시 network나 file 관련 부분이 kernel 모드로
들오옴 (성능 issue)
장점은 유저모드로 올려두니 버그가 있어도 시스템에 영향을 크게 주지 않음.
따라서 쉽게 기능을 추가할수 있음 but 부하가 크다.
Modules
- 대부분의 OS에서 사용
- 객체 지향 접근
- 필요할 때 로딩하는 방식
->OS의 경량화 가능케 함. 리소스 사용 측에서 효율적임
Virtual Machine
OS와 Hardware를 하드웨어처럼 보여주게함.
VM이 하나의 하드웨어처럼 보임
VM위에 독립적인 커널이 존재함.
JVM
jvm은 class loader, java interpreter로 구현되어있음.
-
class loader는
java program.class file, java Api를 로드자바 프로그램을 짜면 compile 후 java Bytecode인 실행파일 생성
이후 java interpreter가 cpu의 명령이 가능한 코드로 변경해줌
인터프리터 때메 실행 부하가 좀 있음.
System boot
def: 컴퓨터를 시작해서 커널을 로딩하는 과정=boot
Bootstrap program (= BIOS,boot loader)
-dram, device등에 문제가 있는지 검사 문제 있으면 부팅 중단
없으면 메인메모리에 디스크의 커널을 로드하고 실행함.
(과정: Mast boot record를 메모리에 로딩, 이 부트 블럭 코드가 디스크에서
커널을 메모리에 로딩함 이 부트 블록이 OS를 선택할 수 있게함)//여기까지 1step
-bios가 구동해 하드웨어 체킹.
