[OS] Concepts, User Interface services, System programs, Linker, Loader, Dual mode

abstract concepts

hardware 위에 operating system, 그 위에 user and other system programs

• os 안에 user interfaces : gui, batch, cli
• system calls : os위에서 동작하는 appliation이 hardware 자원을 쓸 수 있도록(=사용자의 요청을 수행할 수 있도록) 해주는 무언가를 interface로 만든 것
• os의 핵심 기능 kernel(service) : program execution(loader), i/o operations, file systems, communication, resource allocation, accounting, error detection, protection and security 등

user interface services

1. command line interpretier(cli) 를 제공하는 system에서의 해석기 = shell, gui, touch screen interface 등

system programs

1. kernel&user programs 사이 무언가
2. system call의 program
   1. program development&execution을 위한 환경을 제공
   2. os의 핵심 기능을 제어
   3. compiler를 필요로 한다.

Linker and loaders

code 덩어리인 source program → compiler(preprocessor&translator)가 처리 → object file로 묶음
→ linker가 other object files도 이용하면서 → 하나의 실행파일로 만든다
→ loader가 memory에 올려서 process로 만들어주고 → memory에서 프로그램이 실행된다
→ 프로그램 실행 중 필요하다면 공유 라이브러리로 jump하기도 한다.

1. Static Linking
   1. 라이브러리 내 필요한 binary code를 밑에다 붙인다.
2. Dynamic Linking
   1. 프로그램 실행 중 공유 라이브러리로 jump

Dual Mode operation

1. protection : 바로 process가 cpu 위에서 동작하지 않는다 abstraction : system call을 직접 코드에서 사용하는 경우는 드물다. os에 코드가 구현되어있다.
2. user mode & kernel mode

user process의 i/o 요청(system call 형태) → trap to kernel mode → kernel이 cpu 점유해서 find handler in vector table(코드는 os에 구현) → i/o device가 역할 수행하는동안 process는 waiting 상태 → another process run → i/o 완료 → interrupt → interrupt handler → ready queue

1. 자주 쓰이는 명령들은 벡터값으로 mapping 시켜놓는다.
   1. os 한다리 건너는 kernel overhead 줄이기 위해
   2. response time 줄이기 위해
   3. function code의 시작 주소와 연결되어 있다.
   4. system call, interrupt handler… etc
   5. 라이브러리 함수(ex : 표준 C 라이브러리의 system call 함수)를 통해 system call 호출
   6. 라이브러리 함수는 내부적으로 해당 system call 번호를 사용하여 적절한 핸들러 함수를 호출
2. Parameter passing
   1. user program에서 system call 함수 호출할 때
   2. 무조건 register 통해서 system call input parameter(argument) 전달
   3. os에 구현되어있는 system call 번호에 대한 code에서 그 parameter 사용
3. system call service in unix(posix) & windows
   1. posix에는 있는데 windows에는 없는 것도 많다..

kernel의 종류

1. Monolithic kernel
   1. 모든 기능을 한 덩어리로
   2. System call - integrated Kernel - Hardware
   3. by Function calls
2. Micro kernel
   1. 꼭 가져야하는 기능은 kernel이 제공
   2. 그 외의 기능들은 service 형태로 multiple servers가 제공
   3. System call - multiple servers - Microkernel - Hardware
   4. by Massage passing

OS structure

1. Simple structure
   1. batch system : single process system
   2. MS-DOS
2. Monolithinc structure
   1. user programs - OS kernel(모든 기능 : file system, vm, i/o driveres, process control, system services, swapping, networks, protection, interrupt handling, windows, accounting…) - hardware
   2. 장점 : 모두 kernel mode에서 동작하기 때문에 system call단에서 한방에 처리가 가능하다.
      1. memory management, file system, process management 등의 기능이 동일한 주소 영역에 구현되어 있기 때문
   3. 단점 : 소프트웨어 엔지니어링 이슈 (유지보수 이슈), 서로 dependency가 높아진다, 하드웨어의 제약이 존재한다.
3. Layered approach
   1. os가 독립적으로 모듈화 되어있는 계층들로 분리된다.
   2. 장점 : 새로운 기능을 추가/수정할 때 각각의 계층만 수정하면 된다, 유지보수 측면에서 유용
   3. 단점 : 각 계층을 나누는 기준이 모호하다, 현실성이 없다.
4. Microkernel structure
   1. user mode - kernel mode - hardware
   2. 핵심적인 기능(Interprocess Communication, memory management, cpu scheduling) 은 microkernel에, in kernel mode
   3. 그 외 부수적 기능(application program , file system, device driver)은 user mode에 사용자 프로그램으로 구
      1. application add on으로 kernel에 올라가지 않는다.
      2. hardware control은 당연히 kernel에 trap을 걸고 부탁을 해야하지만 논리적 부분만 구현했다는 뜻
      3. 다른 application보다 권한이 더 높아 cpu scheduler에 의해 먼저 수행된다.
   4. 단점 : mode switch가 필요한 구조이므로 (trap → trap handeling → i/o) 오버헤드 발생
5. Moduler approach
   1. 각각 의존성이 없는 것들을 Loadable Kernel Module로 개발
   2. 몇개씩 묶어서 compile하여 kernel을 만든다.
   3. 장점 : image가 작기 때문에 부팅시 memory 부담이 적다.
6. Hybrid approach
   1. gui - application environments and services - kernel environment - hardware
   2. 하나의 시스템에서 두개의 os가 실행된다
      1. 한 os가 시스템을 부팅하고 다른 os는 시스템의 나머지 리소스 사용
   3. ex : iOS
      1. Cocoa Touch - Media Services - Core Services - Core OS