OS Chapter 2 : Operating-System Structures

1. OS가 무엇을 제공하는지,
2. 그것들이 어떻게 제공되는지,
3. 그것들이 어떻게 디버깅 되는지,
4. 그러한 시스템을 설계하기 위한 다양한 방법론들이 무엇인지,
5. OS가 어떻게 만들어지고, 한 커뮤터가 그것의 OS를 어떻게 시작하는지에 대한 내용.

* 운영체제 서비스

• 운영체제는 프로그램 실행을 위한 환경을 제공. 프로그램이나 그러한 프로그램의 사용자에게 서비스들을 제공한다.
• 사용자에게 도움이 되는 기능들인 OS 서비스의 한 집합
• User Interface(UI) : command-line interface(CLI), batch interface, graphical user interface(GUI).
• Program execution : 프로그램 메모리로 불러오고, 실행하기. 프로그램의 실행 종료하기.
• I/O operations
• File-system manipulation
• Communications : 프로세스 간의 의사소통. 의사소통은 두 가지를 통해서 이루어진다. shared memory 기법은, 두 개 이상의 프로세스가 메모리의 한 공유된 부분을 read/write를 하는 것이다. message passing 기법은 미리 정의된 형식의 정보의 패킷들이 OS에 의해 프로세스 사이에서 이동된다.
• Error detection
• 사용자 뿐만 아니라 시스템의 효율적 연산을 위한 기능들인 OS 서비스의 한 집합
• Resource allocation : CPU 사이클, 메인 메모리, 파일 스토리지, I/O 장치들에 대한 할당
• Accounting : 사용자가 이용한 것을 기록하기 위해 사용자를 추적
• Protection and security

* 사용자와 운영체제 인터페이스

• Command Interpreters
• Graphical User Interaces

* System Calls

• System calls는 OS에 의해 이용가능하도록 된 서비스들에 대한 인터페이스를 제공한다. 대부분의 어플리케이션 개발자들은 application programming interface (API)를 이용하여 프로그램을 만든다. Windows API, POSIX API, Java API, 등. 그 장면 뒤에서, 한 API를 구성하는 그 함수들은 일반적으로 어플리케이션 프로그래머를 대신해서 실제 system calls을 불러낸다. API를 사용하여 Portability를 높일 수 있다.
• 대부분의 프로그래밍 언얻르에 대해, run-time support system은 OS에 의해 이용가능한 system calls에 대한 연결 역할을 하는 system-call interface를 제공한다.
• OS에 파라미터들을 넘기는데 사용되는 세 개의 일반적인 방법들이 있다. 가자 ㅇ간단한 접근법은 레지스터에 파라미터들을 넘기는 것이다. 그러나, 어떤 경우에 레지스터보다 더 많은 파라미터가 있을지도 모른다. 이러한 경우에, 그 파라미터는 block, or table, in memory에 저장되고, 그 block의 주소가 레지스터에 파라미터로서 넘겨진다. 이것은 Linux와 Solaris에 의해 취해지는 접근법이다. 파라미터들은 또한 stack에 배치되거나, 프로그램에 의해 pushed되거나, OS에 의해 stack 밖으로 popped 될 수 있다.

* System Calls의 종류

• Process control
• end(normal termination), abort (abnormal termination) : abort가 발생하는 경우, 프로그램이 문제에 빠지고, error trap을 발생시킨다면, 덤프 메모리가 가끔 취해지고, 디버거에 의해 조사될지도 모른다.
• load, execute : 프로그램 불러오고 실행시키기.
• create process, terminate process
• get process attributes, set process attributes : job's priority, maximum allowable execution time 등에 대한 것.
• wait for time
• wait event, signal event
• allocate and free memory
• File management
• create/delete file
• open/close
• read/write/reposition
• get/set file attributres
• Device management
• request/release device
• read/write/reposition
• get/set device attributes
• logically attach/detach devices
• Information maintenance
• get/set time or date
• get/set system data
• get/set process, file, or device attributes
• Communications
• create/delete communication connection
• send/receive messages
• transfer status information
• attach/detach remote devices
• Message passing이 더 작은 양의 데이터를 교환하는데 유용하다. 왜냐하면 어떠한 conflicts들이 피해질필요가 없기 때문이다. 또한 intercomputer communication에 대해 shared memory보다 구현이 더 쉽다. Shared memory는 최대 속도와 커뮤니케이션의 편리성을 허용하는데, 그것이 컴퓨터에서 발생할 때 메모리 전송 속도에서 처리될 수 있기 때문이다. 그러나, 메모리를 공유하는 프로세스 사이의 protection과 synchronization의 영역에 문제가 존재한다.
• Protection
• Protection은 컴퓨터 시스템에 의해 제공되는 resources에 대한 접근권을 통제하는 기제를 제공한다.
• set/get_permission()
• allow/deny_user()

* System Programs

• System programs, 또는 system utilities라고 알려진 것은 프로그램 개발과 실행을 위한 편리한 환경을 제공한다.
• File management : 이러한 프로그램들은 일반적으로 파일과 폴더를 생성/제거/복사/재명명/출력/dump/열거/조작을 한다.
• Status information
• File modification
• Programming-language support : 컴파일러, 어셈블러, 디버거, interpreters가 운영체제와 함께 제공된다.
• Program loading and execution : absolute loaders, relocatable loaders, linkage editors, overlay loaders. Debugging system for higher-level languages or machine language.
• Communications : 프로세스들, 사용자, 그리고 컴퓨터 시스템 사이의 가상 연결을 생성하는 기제를 제공한다.
• Background services : 계속해서 작동하는 시스템-프로그램 프로세스들은 services, subsystems, or daemons로 알려져있다.

* 운영체제 설계와 구현

• 시스템의 설계는 하드웨어의 선택과 시스템의 종류에 의해 영향을 받는다. 그러나 일반적으로 요구사항들은 두 개의 기본적인 그룹으로 나눠질 수 있다 : 사용자 목표와 시스템 목표.
• 한 가지 중요한 원칙은 기제(mechanism)로부터 정책(policy)를 분리하는 것이다. 기제는 어떤 것을 어떻게 할지를 결정한다. 정책은 무엇이 되어야 할 지를 결정한다. 정책은 시간과 장소에 따라서 변할 가능성이 높다. 최악의 겨웅에 정책의 각 변화가 밑의 메커니즘의 변화를 요구할 것이다. 정책에서의 변화에 민감하지 않은 일반적인 메커니즘이 좀 더 바람직할 것이다. 정책은 모든 자원 할당에 있어서 중요하다.
• 운영체제의 중대한 성능 향상은 훌륭한 어셈블리 언어 코드보다는 더 좋은 자료구조와 알고리즘의 결과일 가능성이 높다. 게다가, OS가 클지라도, 오직 코드의 작은 양만이 높은 성능에 중요하다; interrupt handler, I/O manager, memory manager, CPU scheduler는 아마도 가장 중요한 루틴이다.

* 운영체제 구조

• 흔한 접근법은 task를 하나의 monolithic 시스템을 갖기 보다는 작은 컴포넌트 또는 모듈로 분할 하는 것이다. 이러한 모듈들 각각은 잘 정의된 시스템의 부분이여야 하고, 세심하게 정의된 입력, 결과, 기능이 있어야 한다.
• 적절한 하드웨어 지원으로, 운영체제는 더 작고 이전의 것보다 더 적절한 조각들로 분해될 수 있었다. 탑다운 접근법 하에서, 전체 기능과 특징들은 결정되고, 컴포넌트들로 분리된다. 숨겨진 정보들은 또한 중요한데, 왜냐하면 프로그래머들이 로우레벨 루틴을 구현하는데 자유롭게 만들기 때문이다. 한 시스템은 여러 방법에서 modular하게 만들어질 수 있는데, 한 방법은 layered approach이다.
• operating-system layer는 데이터와 그러한 데이터를 조작할 수 있는 연산으로 구성된 abstract object의 구현이다. layered 접근법의 주된 이점은 construction과 debugging의 간단함이다. 그 레이어들은 각각이 functions(operations)를 사용하고, 더 낮은 level layers의 서비스들을 사용하도록 선택된다. 이 접근법은 디버깅과 시스템 검사를 간단하게 한다. layered approach의 주된 어려움은 적절히 다양한 layers들을 정의하는 것이다. layered implementations의 마지막문제는 다른 것들 보다 덜 효율적인 경향이 있다.
• Microkernel 방식은 커널에서 모든 불필요한 컴포넌트를 제거하고, 그것들을 시스템과 user-level programs로 구현하여 OS를 구조화한다. 그 결과는 더 작은 커널이다. 어떤 것이 커널에 남아야 하고, user space에서 구현되어야 하는지에 대해 관련된 일치된 합의가 없다. 그러나, microkernels은 communication facility 외에도 최소한의 process and memory management를 제공한다. microkernel의 주된 기능은 client program과 user space에서 또한 작동하는 다양한 서비스 사이의 communication을 제공하는 것이다. communication은 message passing을 통해 제공된다.
• OS design의 가장 좋은 현재 방법론은 loadable kernel modules이다. 여기에서 커널은 코어 컴포넌트들의 한 집합과 modules를 통한 부가적인 서비스에서의 links를 가지고 있다. boot time or run time 동안 둘 중 하나에서. 이러한 design의 종류는 Solaris, Linux, Mac OS Xrkxdms UNIX의 현대 구현에서, 뿐만 아니라 Windows에서 흔하다. 그 디자인의 아이디어는 커널이 작동하고 있을 때, 다른 서비스들이 동적으로 구현되는 동안 커널이 core services를 제공하는 것이다. services를 동적으로 linking하는 것은 kernel에 직접적으로 새로운 기능을 추가하는 것보다 더 선호된다. 그 후자의 것은 변화가 만들어질 때 마다 커널을 재컴파일 하는 것을 요구한다. 

* 운영체제 디버깅

• 디버깅은 bottlenecks을 제거하여 성능을 향상햐려 하는 performance tuning을 또한 포함한다. 
• 한 프로세스가 실패한다면, 대부분의 운영체제는 system operators 또는 사용자에게 문제가 발생했다고 경고하기 위해 log file에 에러 정보를 쓴다. 운영체제는 또한 core dump - 프로세스의 메모리에 대한 캡쳐-를 취할 수 있고,그것을 나중의 분석을 위해 파일로 저장할 수 있다 (Memory는 컴퓨팅의 초기 시절에 "core"라고 언급되었다.) 프로그램들과 core dumps를 작동시키는 것은 debugger에 의해 조사되어질 수 있고, 프로그래머가 그 코드와 프로세스 메모리를 조사할 수 있게 한다.
• user-level process code를 디버깅하는 것은 도전이다. OS Kernel 디버깅은 커널의 사이즈와 복잡성, 하드웨어에 대한 제어, 사용자 수준의 디버깅 도구의 부족 때문에 훨씬 더 복잡하다. kernel에서의 실패는  crash라고 불려진다. crash가 발생할 때, 에러 정보는 log file에 저장되고, 그 메모리 상태가 crash dump에 저장된다.
• OS 디버깅과 프로세스 디버깅은 이러한 두 tasks의 다른 특성으로 인해 빈번하게 다른 도구와 기법을 사용한다. 
• processing bottlenecks를 제거하여 성능 향상을 하는게 performance tuning인데, bottlenecks를 확인하기 위해, 우리는 시스템 성능을 감시할 수 있어야 한다. 따라서, 운영체제는 시스템 행동의 수치를 연산하고 보여줄 수단을 가져야만 한다. system behavior의 trace listings이라는것을 만들어 운영체제 그것을 한다.

* 운영체제 생성

• 운영체제는 다양한 주변 설정이 있는 다양한 장소에서 기계의 어떤 기계의 한 종류에 작동하도록 설계된다. 그 시스템은 그러고나서 각 특정한 컴퓨터 장소에 대해 설정되거나 생성되어야만 한다. 그리고 이것은 system generation SYSGEN이라고 알려진 프로세스이다.
• 운영체제는 일반적으로 디스크, CD-ROM 또는 DVD-ROM 또는 ISO image로 배포된다. 한 시스템을 생성하기 위해서 우리는 특별한 프로그램을 사용한다. 이 SYSGEN 프로그램은 주어진 파일로부터 읽어들이고, 하드웨어 시스템의 특정한 설정과 관련된 정보를 그 system의 operator에 요청하거나, 무슨 컴포넌트들이 거기 있는지를 결정하기 위해 직접적으로 하드웨어를 조사한다. 정보의 다음의 종류가 결정되어야 한다:
• 무슨 CPU가 사용되었는가? 무슨 옵션(확장된 명령어 집합, 부동소수점 연산, 등)이 설치되었는가? 여러 CPU 시스템에 대해, 각 CPU는 설명될지도 모른다.
• 어떻게 boot disk가 포맷화되어있을 것인가? 그것은 얼마나 많은 sections, or "partitions"로 분리될 것이고, 무엇이각 파티션으로 들어갈 것인가?
• 얼마나 많은 메모리가 이용가능한가? 
• 무슨 장치가 이용가능한가? 그 시스템은 각 디바이스를 어떻게 address할지 (the device number), device interrupt number, device의 종류와 모델, 어떤 특별한 device 특징을 알 필요가 있다.
• 무슨 운영체제 옵션이 요구되는가? 또는 무슨 파라미터 값이 사용될 것인가? 이러한 옵션들 또는 값들은 어떤 사이즈의 버퍼가 사용될지, 무슨 CPU-sceduling알고리즘이 요구되는지, 지원되는 프로세스의 최대 개수가 무엇인지 등을 포함할지도 모른다.

* System Boot

• kernel을 불러와서 컴퓨터를 시작하는 것의 절차는 system을 booting하는 것으로 알려져 있다. 대부분의 컴퓨터 시스템에서, bootstrap program or bootstrap loader로 알려진 작은 코드가 커널을 찾고, 그것을 메인 메모리로 불러오고, 그것의 실행을 시작한다. 그 코드(프로그램)은 read-only memory(ROM의 형태로 있다. 
• bootstrap program은 기계의상태를 결정하기 위해 진단을 실행한다. 또한 그것은 CPU 레지스터부터 디바이스 컨트롤러, 메인 메모리의 내용까지 그 시스템의 모든 측면을 초기화한다. 그 후 곧 그것은 운영체제를 시작한다.