시스템 서비스
사용자 프로그램입니다 !!! 프로그램 개발, 실행에 있어서 편리한 환경을 제공합니다. 파일 관리, 저장, 프로그램 언어, 프로그램 로딩 및 실행, 통신, 백그라운드 서비스, 어플리케이션 프로그램(OS를 살 때 따라오는 프로그램들)
시스템 콜 = 커널 기능 호출
시스템 프로그램 = 운영체제가 제공하는 사용자 프로그램
두개는 다른 개념입니다 !!!
File modification
- 텍스트 에디터로 생성, 저장
프로그램 언어 지원
- compilers, assemblers, debuggers, interpreters
프로그램 로딩, 실행
- loader, linker 제공
통신
- 프로세스, 유저, 컴퓨터 시스템 간의 가상 연결 생성
백그라운드 서비스
- services, subsystems, daemons
어플리케이션 프로그램
- = 시스템 프로그램
- OS를 사면 기본적으로 설치되어 있는 프로그램
Linkers, Loaders
소스 코드는 object file(물리적 메모리에 로드될 파일)로 컴파일 됩니다. 링커는 이 파일들을 하나의 실행가능한 binary 파일로 합칩니다. (모든 사용하는 라이브러리도 함께 단일 실행파일로 구성합니다. static link)
C 코드 > Object 코드 > 실행파일 > 메모리에 로드
최근에는 모든 라이브러리 파일을 링크하지 않습니다. 대신, dynamically linked libraries 을 사용합니다. (프로그램에서 라이브러리 호출 시 라이브러리 코드로 가서 잠깐 실행 후 다시 돌아와서 본래의 코드를 실행합니다.) 이는 시스템 콜의 방식과는 다릅니다.
어플리케이션 = OS Specific
윈도우에서 컴파일한 어플리케이션은 맥에서 실행할 수 없습니다. (각 운영체제가 제공하는 시스템 콜이 다르기 때문입니다.)
이를 위해서
1. interpreted language : python, ruby 등을 사용
2. 다양한 운영체제에서 사용할 수 있는 인터프리터 사용
3. VM 을 포함하는 언어로 작성 (자바처럼)
4. standard language (c언어 같은) 사용
하지만 여전히 크로스 플랫폼 어플리케이션 개발은 어렵습니다.
OS 디자인 및 구현
정답이 없습니다 !! 유저의 목표와 시스템의 목표는 약간 다릅니다.
디자인
유저 목표 : 사용하기 편하고, 배우기 쉽고, 신뢰성 높고 안전하고 빠른
시스템 목표 : 디자인하기 쉽고, 구현과 유지보수가 쉽고 신뢰성 높고 에러가 없는, 효율적인
Policy
- 무엇을 할 것인지
Mechanism
- 어떻게 할 것인지
중요한 것은 policy에서 mechanism을 분리하는 것 입니다.
구현
- 중요한 부분은 어셈블리어
- 대부분 C, C++도 씁니다.
- 커널은 빨라야 하기 때문에 C언어로 작성됩니다.
- high-level 언어는 이식성이 좋지만 느립니다.
