# Outline:

• Operating system services
• System calls
• os design & implementation
• Operating System Structure
• System boot

1.Operating system services:

1. For users:

   • User interface:
   • Program execution
   • I/O operations
   • File-system manipulation(create,delete,search file)
   • communications(프로세스간의 커뮤니케이션)
   • error detection

2. For efficiency:

   • resource allocation
   • accounting(하드웨어 사용 통계자료 제공)
   • protection
   • security(user authentication: login/pwd)

• User interface:-CLI(command line interface): Shell을 통해 CLI가 구현되어있는 구조
  -Shell(program): command를 받아서 해석하고, 수행하는 역할. shell 자체에 명령어를 실행하는 코드를 포함시키면 shell 크기가 너무 커진다. shell은 별도로 존재하는 실행파일을 찾아서 실행시켜주는 역할이다.
  -GUI(graphic user interface): OS,UNIX,LINUX
  -Batch interface: commands are collected into files and those files are executed.(여러개의 커맨드를 하나의 스크립트 파일로 만들고 그 파일이 실행되는 개념)
  

2.System call:

• kernel mode에 접속하는 방법:

1. Hardware interrupt(timer interrupt)
2. Trap(software interrupt): exception, system call

interrupt가 발생하면 CPU는 무조건적으로 ISR을 실행해야하므로, kernel mode로 접속한다.

Ex) cp A.txt B.txt 를 입력하였을때 시스템콜이 실행되는 과정:

• API:
  - 각각 다른 OS에서 동일한 기능인데 함수명을 다르게 사용하면 프로그래머들은 복잡하고 불편해진다. 그래서 함수명을 통일해서 쓰는 라이브러리를 만들었다. -> ex) 유닉스계열에서의 POSIX
  - EX: POSIX API: malloc() -> system call: sbrk()
  - application program -> 라이브러리 함수 호출 -> 라이브러리 함수 내에서 system call 호출
  - INDIRECTLY invoked system call
  - 근데 라이브러리에서 system call을 발생시키는데 OS마다 system call명이 다른데 그건 어떻게 처리하는거지요?
• WHY use API instead of system call directly:
  - code Portability: OS마다 시스템콜이 다르기 때문에 공통 API를 사용한다.
  

• System Call Interface(Table):
  - system call은 Kernel에 테이블 형태[system call#,함수주소]로 구현되어있다.
  - app -> common api -> system call -> system call interface look-up

write()의 시스템콜 #을 system call interface에서 찾아서 write() system call을 실행한다.

1. user task 에서 fork(): common api 실행
2. common api 내부에서 eax에 system call # 저장 + int $0x80(trap: system call==interrput) interrupt 호출
3. IDT(==interrupt vector, interrupt description table(모든 interrupt에 대한 정보를 가지고 있다.))에서 전달받은 interrupt #에 해당하는 ISR 실행(==시스템콜)
4. 시스템콜을 실행하기 위해 %eax에 저장되어 있는 system call #을 system call table interface에서 찾는다.
5. 시스템콜 #에 해당하는 시스템콜 실행.

• 시스템콜에 parameter 전달하는 방식:
  1. 레지스터에 인자를 저장하는 방식: 레지스터에 인자를 저장하는 이유는 User-mode space 내용을 kernel-mode space에 넘겨주기 위해서이다.
  2. 인자를 block에 저장하고 block의 주소를 레지스터에 저장하는 방식: 인자를 block에 저장하는 이유: 인자를 담을수있는 레지스터의 개수가 한정되어 있기 때문이다.

3.OS의 디자인:

policy(수행하는 작업)의 변화에 상관없는 메커니즘이여야한다.

Layered approach:

• OS가 많은 레이어로 나누어진다.
• 각각의 레이어들은 더 낮은 레이어에 의해 제공되는 operation들에 의해 실행된다.
• top layer: user interface , bottom layer: H/W
• 이점: simplicity of contruction and debugging
  

micro-kernel based approach:

• kernel에 최소한의 기능(scheduling,process management)를 제외하고 최대한 많은 기능을 user space에 올린것 (EX: file system을 수정하려면 kernel을 수정할필요 없이 user space에서 수정하면 된다.)
• 제약: performance overhead for message passing(task간 communication)

Modules:

• 기능별로(function) module로 나눈다. (OS 내에 A,B,C,D 등등 모듈으로 나누어지는것)
• 각각의 모듈들이 커널 런타임에 로딩,언로딩이 가능하다.
• Linux= Layerd+module approach 방식이다.
• 언제 사용할까? 새로운 하드웨어를 pc에 추가하려면 device driver(하드웨어를 구동하는 소프트웨어)가 필요한데 디바이스가 새로 추가될때마다 커널을 리컴파일할필요없이 커널에 로딩,언로딩한다.

virtual machine:

• virtualization layer가 만들어진다.
  
  

4.System boot:

• Booting= 전원을 켜면 자동으로 BootStrap loader(ROM에 저장되어있음)가 실행된다 -> bootstrap loader가 OS를 메모리에 로딩해준다 == Kernel(OS)에 제어권을 넘기는것 == OS의 MAIN 함수의 첫번쨰 라인이 실행되도록 해준다.

• Booting 방식:

  1. Single-step approach: Bootstrap loader에서 커널 로딩을 다하는것
  2. Two-step approach: OS를 사용하기 위해서는 HW를 초기화해주는과정이 필요하는데 초기화 과정코드가 꽤 길수있다.-> 부팅에 필요한 코드를 bootstrap loader가 다 담지못할때 boot block을 크게 잡아서 boot block에서 kernel을 로딩해준다.