ch02 시스템 구조

2.1 운영체제 서비스
운영체제는 프로그램 실행 환경을 제공

운영체제 서비스

1. 사용자 인터페이스(User Interface)
   모든 운영체제는 UI를 제공한다.
   - 명령어 라인 인터페이스(Command-Line Interface, CLI): 문자열 명령과 입력
   - 배치 인터페이스(Batch Interface):
      명령어와 명령어를 제어하는 디렉티브(directive)가 파일 형태로 입력되고 그 파일 실행
   - 그래픽컬 사용자 인터페이스(Graphical User Interface, GUI):
      입출력을 지시하고, 메뉴를 선택하는 지시 장치와 문자열을 입력하는 키보드 포함

2. 프로그램 실행(Program Execution)
   프로그램은 메모리에 적재되어 실행된다.

3. 입출력 연산(I/O Operation)
   실행 중인 프로그램은 입출력을 요구할 수 있다.

4. 파일 시스템 조작(File System manipulation)
   파일 시스템, 디렉터리의 접근 허가 및 거부, 파일 생성 및 삭제 및 찾기

5. 통신(Communication)
   프로세스와 다른 프로세스와 정보를 교환하는 통신(동일한 컴퓨터 내, 네트워크에 의해 묶인)
   통신은 공유 메모리를 통해서 구현, 메세지 전달(Message passing) 기법에 의해 구현

6. 오류 탐지(Error detection)
   운영체제는 모든 가능한 오류를 의식해야 한다.
   오류: CPU, 메모리 하드웨어 오류, 입출력장치(패리티 오류, 네트워크 접속 실패)
   사용자 프로그램(연산의 오버플로우, 불법적인 메모리 위치에서의 접근 시도, CPU 오버헤드)

7. 자원 할당(Resource Allocation)
   다수의 사용자, 작업들이 동시 실행될 때, 각각에 자원을 할당해야 한다. -> CPU 효율적 사용

8. 회계(Accounting)
   어떠한 컴퓨터 자원을 사용하고 있는가 통계 및 개선을 위한 자료 수집

9. 보호(Protection)와 보안(Security)
   시스템 자원에 대한 접근을 통제, 인증 및 절차

2.2 사용자 운영체제 인터페이스(User Operating-System Interface)

2.2.1 명령 해석기(Command-Interpreter)
셸(Shell): 선택할 수 있는 여러 명령어 해석기를 제공하는 시스템 안의 해석기

UNIX, Linux 시스템에서 Bourne shell, C shell, Korn shell

2.3 시스템 호출(System Calls)

시스템 호출은 운영체제가 제공하는 서비스에 대한 인터페이스를 제공한다.

특정 저 수준 작업(예를 들면, 하드웨어를 직접 접근해야 하는 작업) 어셈블리 명령을 사용,
일반적으로는 C, C++언어로 작성된 루틴 형태를 제공한다.

대부분의 응용 개발자들은 응용 프로그래밍 인터페이스(Application Programming Interface, API)에 따라 프로그램을 설계. API는 각 함수에 전달되어야 할 매개변수들과 프로그래머가 기대할 수 있는 반환 값을 포함하여 응용 프로그래머가 사용 가능한 함수의 집합을 명시.

API 예) Win32 API(Windows), POSIX API(UNIX, Linux), Java API

API 함수를 호출하는 것과 커널의 관련된 시스템 호출(System call)을 호출하는 것에는 강한 상관 관계가 존재한다.

프로그래밍 언어들을 위한 실행 시간 지원 시스템(컴파일러에 포함된 라이브러리에 내장된 함수의 집합)은 운영체제가 제공하는 시스템 호출에 대한 연결로서 동작하는 시스템 호출 인터페이스를 제공한다. 이 인터페이스는 API 함수의 호출을 가로채어 필요한 운영체제 시스템 호출을 부른다.

각 시스템 호출에는 번호가 할당되며, 번호에 따라 인덱스되는 테이블을 유지한다.

2.4 시스템 호출의 유형

시스템 호출은 다섯 가지의 중요한 범주 즉, 프로세스 제어, 파일 조작, 장치 조작, 정보 유지 보수 와 통신과 보호로 묶일 수 있다.

> 프로세스 제어(Process Control) - 끝내기(end), 중지(abort) - 적재(load), 실행(execute) - 프로세스 생성 및 종료 - 프로세스 속성(attribute) 획득 및 설정 - 시간을 기다림 - 사건을 기다림(wait event), 사건을 알림(signal event) - 메모리 할당 및 자유화 > 파일 조작(File Manipulation) - 파일 생성(create file), 파일 삭제(delete file) - 열기(open), 닫기(close) - 읽기, 쓰기, 위치 변경(reposition) - 파일 속성 획득 및 설정 > 장치 관리(Device Management) - 장치를 요구(request devices), 장치를 방출(release devices) - 읽기, 쓰기, 위치 변경 - 장치 속성 획득 및 설정 - 장치의 논리적 부착(attach) 및 분리(detach)  > 정보 유지(Information Maintenance) - 시간과 날짜의 설정과 획득 - 시스템 데이터의 설정과 획득 - 프로세스, 파일, 장치 속성의 획득 및 설정  > 통신(Communication) - 통신 연결의 생성, 제거 - 메세지의 송신, 수신 - 상태 정보 전달 - 원격 장치의 부착(attach) 및 분리(detach)

	Windows	UNIX
프로세스 제어	CreateProcess() ExitProcess() WaitForSingleObject()	fork() exit() read()
파일 조작	CreateFile() ReadFile() WriteFile() CloseHandle()	open() read() write() close()
장치 조작	SetConsoleMode() ReadConsole() WriteConsole()	ioctl() read() write()
정보 유지 보수	GetCurrentProcessID() SetTimer() Sleep()	getpid() alarm() sleep()
통신	CreatePipe() CreateFileMapping() MapViewOfFile()	pipe() shmget() mmap()
보호	SetFileSecurity() InitlializeSecurityDescriptor() SetSecurityDescriptorGroup()	chmod() umask() chown()

2.4.1 프로세스 제어(Process Control)
실행 중인 프로그램은 실행을 정상적(끝내기) 또는 비정상적(중지)으로 끝낼 수 있어야 한다.

만약 비정상적으로 중지하기 위해 시스템 호출이 행해지거나 또는 프로그램에 문제가 발생해 오류 트랩(trap)을 유발할 경우 덤프(dump) 가 행해지고 오류 메세지가 생성된다.

이 덤프(dump)는 디스크에 기록되고 문제의 원인을 결정하기 위해 디버거(Debuger, 버그를 찾고 수정하는데 도움을 주는 시스템 프로그램)에 의해 검사 될 수 있다. 여러 가지 상황에서 운영체제는 명령 해석기로 제어를 전달해야 한다. 이어 다음 명령을 읽는다.

한 프로그램을 실행하고 있는 프로세스나 잡(job)이 다른 프로그램을 적재(load)하고 실행(execute)하기를 원할 수 있다. 이 기능은 명령 해석기 사용자 명령, 마우스의 클릭(click) 혹은 일괄 처리 명령을 통하여 지시된 프로그램을 실행할 수 있게 한다.

만약 새로운 프로그램이 종료되었을 때 제어가 기존 프로그램으로 되돌아간다면, 우리는 반드시 기존 프로그램의 메모리 이미지를 보관해야 한다. 따라서 우리는 실질적으로 한 프로그램이 다른 프로그램을 호출하는 기법을 만든 셈이다.

만약 우리가 새로운 job 이나 프로세스 혹은 집합을 생성한다면, 우리는 그들의 실행을 제어할 수 있어야 한다. 이러한 제어는 job 의 우선순위, 최대 허용 실행 시간 등을 포함하여 속성들을 결정하고 재설정(reset) 가능 해야 한다. 또한 잘못되었거나 필요 없을 경우 종료(terminate process).

새로운 자이나 프로세스를 생성한 후에는 이들의 실행이 끝나기를 기다려야 할 필요가 있다.(wait time)

그리고 보다 가능성이 큰 경우는 우리가 특정 사건일 일어날 때까지 기다려야 하고, 사건이 발생하면 신호를 보내야 한다. (wait event, signal event).

빈번하게 둘 이상의 프로세스들은 데이터를 공유한다. 공유되는 데이터의 일관성을 보장하기 위해서 운영체제는 종종 프로세스가 공유 데이터를 잠글 수 있는 시스템 호출을 제공하여 다른 프로세스의 접근을 막고, 조정(coordination)을 해야 한다.

FreeBSD는 다중 태스킹 시스템의 예.

사용자가 시스템에 로그인할 때 사용자가 선택한 셸이 실행된다.

다른 프로그램이 실행되는 동안 명령 해석기는 계속 실행을 할 수 있다.

새로운 프로세스를 시작하기 위해 셸은 fock() 시스템 호출을 실행한다. 그런 다음, 선택된 시스템이 exec() 시스템 호출을 통해 메모리에 적재되고, 이어 그 프로그램이 실행된다. 명령이 내려진 방법에 따라 셸은 프로세스가 종료하기를 기다리거나 또는 “백그라운드(background)”에서 프로세스를 실행한다.

FreeBSD

Process D

Free Memory

Process C

해석기

Process B

Kernel

2.4.2 정보의 유지(Information Maintenance)

많은 시스템들은 메모리를 덤프(dump)하기 위한 시스템 호출을 제공하며, 이것은 디버깅 하는데 유용하다. 프로그램 추적(trace)은 각 명령어가 실행될 때 이들을 하나씩 나열하며, 이러한 시스템 호출은 보다 소수의 시스템에서만 제공된다. 심지어 마이크로프로세서들도 단일 단계(single step)라고 알려진 CPU 모드를 제공하는데, 여기서 는 매번 명령어 실행 후 CPU에 의해 트랩이 실행된다. 트랩은 통상 디버거(Debugger)에 의해 포착된다.

많은 운영체제는 프로그램의 시간 프로파일(time profile)을 제공한다. 시간 프로파일은 그 프로그램이 특정 위치 혹은, 위치의 집합에서 실행한 시간의 양을 나타낸다.

2.6 운영체제 설계 및 구현 (Design and Implementation)

2.6.1 설계 목표(Design Goals)

시스템을 설계하는 데에 첫째 문제점은 시스템의 목표와 명세를 정의하는 일이다.

시스템 설계는 최상위 수준에서는 하드웨어와 시스템 타입(일괄처리, 시분할, 단일 사용자, 다중 사용자,
분산, 실시간, 범용)의 선택에 의해 영향을 받을 것이다.

시스템은 설계, 구현, 유지 보수가 쉬워야 하며, 적응성, 신뢰성, 무오류, 효율성을 가져야한다.

2.6.2 메커니즘과 정책(Mechanisms and Policies)

메커니즘으로부터 정책을 분리한다.

메커니즘은 어떤 일을 어떻게 할 것인가를 결정하는 것이고, 정책은 무엇을 할 것인가를 결정하는 것이다.

 ex) 타이머 구조는 CPU 보호를 보장하기 위한 메커니즘이지만 특정 사용자를 위해 얼마나 오랫동안
    설정할 지를 결정하는 것은 정책적 결정이다.

정책과 메커니즘의 분리는 융통성을 위해 아주 중요하다.

정책은 장소가 바뀌거나 시간이 흐름에 따라 변경될 수도 있다.

최악의 경우, 정책의 각 변경이 저변에 깔려 있는 메커니즘의 변경을 요구하게 된다.

정책의 변경에 민감하지 않은 일반적인 메커니즘이 보다 바람직하다. 그렇게 되면 정책의 변경은

시스템의 매개 변수만을 재정의하는 것을 필요로 한다.

자원의 할당 여부를 결정할 필요가 있을 때마다 정책을 결정해야 한다.

질문이 무엇(what)이 아니라 어떻게(how)일 때마다, 반드시 결정되어야 하는 것은 메커니즘이다.

2.6.3 구현

전통적으로 운영체제는 어셈블리어로 작성되었다.

그러나 지금은 대부분 운영체제가 C, C++와 같은 고급 언어로 작성된다.

고급언어로 작성할 경우, 빨리 코드를 작성할 수 있고, 간결하며 이해하기 쉽고, 디버그하기도 쉽다.

단, 속도가 느리고 저장장치가 많이 소요되는 것이다.

운영체제의 주요 성능 향상은 우수한 어셈블리어 코드보다는 좋은 자료 구조와 알고리즘의 결과일  가능성이 크다. 메모리 관리자와 CPU 스케줄러가 가장 중요한 루틴일 것이다.

2.7 운영체제 구조(Operating-System Structures)

2.7.1 간단한 구조(Simple Structure)

잘 정의된 구조를 갖지 못한 상용 운영체제는 많이 있다. 작고 간단하며 제한된 시스템으로 출발하였지만, 원래의 범위 이상을 발전된 것들이다.

대표적으로 MS-DOS, 최초의 UNIX

MS-DOS는 인터페이스와 기능 계층이 잘 분리되어 있지 않다.

즉 하드웨어에 직접적으로 쓰기가 가능하여, 오류가 있는(또는 악의적인) 프로그램으로부터 취약하게 만들었다. 따라서 사용자 프로그램이 고장 나면 시스템 전체가 고장 나게 된다.

물론 그 당시에는 하드웨어 기능에 제한을 받았다.

UNIX 또한 하드웨어의 기능에 제한 받는 시스템이었다.

UNIX는 두 부분, 커널과 시스템 프로그램으로 구성되어 있다.

위의 사진과 같이 인터페이스 아래와 물리적 하드웨어 위의 모든 것이 커널이다.

이러한 기능은 하나의 계층으로 결합하기에는 엄청나게 많은 기능이다. 이 모놀리식 구조는

구현하기 어렵고, 또 유지 보수하기도 어려웠다.

2.7.2 계층적 접근(Layered Approach)

운영체제는 작고 보다 적절한 조각으로 분할될 수 있다. 운영체제는 컴퓨터와 그 컴퓨터를 사용하는 응용에 대해 훨씬 더 큰 제어를 유지할 수 있다. 구현자들은 시스템의 내부 동작과 모듈식 운영체제의 생성에 변화를 줄 수 있는 보다 큰 자유를 갖게 되었다.

하향식(top-down) 접근법 하에서는 전체적인 기능과 특징이 결정되고 구성요소로 분리된다. 정보의

은폐 또한 중요하다.

시스템은 다양한 방식으로 모듈화될 수 있다.

계층적 접근에서는 운영체제는 여러 개의 층으로 나뉘어진다. 최하위 층은 하드웨어이고, 최상위 층은 추상된 객체의 구현이다. 사용자 인터페이스이다.

운영체제 층은 데이터와 이를 조작하는 연산으로 구성된다.

계층적 접근 방식의 주된 장점은 구현과 시스템의 검증과 디버깅의 간단함에 있다.

계층적 접근 방법의 가장 어려운 점은 여러 층을 적절히 정의하는 것을 포함한다.

문제점은 다른 유형의 구현 방법보다 효율성이 낮다는 것이다.

2.7.3 모듈(Modules)

모듈화 커널을 만들기 위해 운영체제를 설계하는 가장 좋은 최근의 기술은 아마도 객체 지향 프로그래밍 기법을 사용하는 것이다.

이 접근법에서는 커널은 핵심적인 구성요소의 집합을 가지고 있고 부팅 때 또는 실행 중에 부가적인 서비스들을 링크한다.

이러한 설계는 핵심 서비스를 제공할 수 있게 할 뿐 아니라 특정 기능들을 동적으로 구현할 수 있게 한다.

2.8 가상기계(Virtual Machines)

가상기계의 기본적인 착상은 한 컴퓨터의 하드웨어(CPU, 메모리, 디스크 드라이브, 네트워크 인터페이스 카드 등)를 추상화하여 다수의 다른 실행 환경을 제공하도록 하는 것이다. 그리하여 각각의 개별적인 실행 환경이 자신만의 개별적인 컴퓨터를 사용하는 가상 환경을 만들어 낸다.

2.8.1 장점(Benefits)

가상 기계는 동일한 한정적인 하드웨어를 공유하면서 다수의 다른 실행 환경(운영체제)을 동시 실행할 수 있다는 점이다.

가상기계들끼리 서로 보호되는 것처럼 호스트 시스템도 가상기계들로부터 보호된다는 것이다

여러 시스템 자원이 완전히 보호되므로 보안의 문제점이 없다.

또한 가상기계들이 네트워크를 구성하게 하는 것이 가능하다.

2.8.2 반가상화(Para-virtualization)

반가상화는 게스트 운영체제를 실제 시스템을 가지고 있다고 속이려고 하기보다 게스트가 선호하는 시스템과 유사하지만 동일하지 않은 시스템을 게스트에게 제공하는 것이다.

게스트가 반가상화된 하드웨어 실행되려면 수정이 불가피하다.

2.8.3 구현(Implementation)

가상화는 유용하지만 구현하기 어렵다. 또한 일정 수준의 하드웨어 지원 없이 가상화는 불가능하다.

p89