운영체제의 구조

Operating System Services

Os services의 관점

• OS는 프로그램과 하드웨어 사이에서, 프로그램의 실행을 위한 환경을 제공한다.
• OS는 유저와 시스템에게 다양한 서비스를 제공한다.

 

OS Interfaces

 

User interface

• Command Interpreter(CLI)
  • shell이라고 불린다.
  • 목표 : 다음 사용자가 지정한 명령을 수신하고 실행하는 것
• GUI(Graphical User Interface)
  • mouse, folder, icons, touch screen... etc.
• batch interface

 

Program Execution

• 시스템은 프로그램을 메모리에 로드하고 , 실행하고, 실행을 끝낼 수 있어야 한다.

I/O operation

• OS는 효율과 보안을 위해, 사용자가 직접 입출력 장치를 조작하지 않고, OS를 거치도록 해야 한다.
• Printing, scanning, DVD recording

File-system manipulation

• 파일 읽기, 쓰기, 생성, 삭제, 검색. + 사용자가 파일에 접근을 못하도록 막기도 한다.

Communications

• 프로세서끼리 정보교환
  • shared memory : 여러 프로세스가 메모리의 한 부분을 공유하도록
  • Message passing : 프로세스 간에 message(정보)를 주고받는 것

Message passing이 Shared memory보다 더 느리다.

 

Error detection

• OS는 하드웨어 수준에서 발생하는 에러, 소프트웨어 수준에서 발생하는 에러를 탐지하고 고칠 수 있어야 한다.

 

OS Services for Efficient Operation

• Resource allocation
  • 컴퓨팅 자원은 여러 프로세스 간에 할당되어야 합니다
  • 자원 : CPU, memory , file storage, I/O devices
• Accounting
  • 어떠한 프로세스가 자원을 얼마나 사용했는지 계속해서 추적
• Protection and Security
  • 시스템 자원으로의 모든 접근은 통제되어야 한다.
  • 프로세스끼리는 서로 방해하지 않아야 한다.

System calls

운영체제의 커널이 제공하는 서비스에 대해, 응용 프로그램의 요청에 따라 커널에 접근하기 위한 인터페이스이다.
보통 C나 C++과 같은 고급 언어로 작성된 프로그램들은 직접 시스템 호출을 사용할 수 없기 때문에 고급 API를 통해 시스템 호출에 접근하게 하는 방법이다.

 

시스템 콜이 사용되는 경우

가정 : 하나의 파일에서 데이터를 읽어서 다른 파일에 복사하는 작업

• 사용자로부터 파일 이름을 요청받을 때 사용되는 시스템 콜
  • 입력 프롬포트 사용 : 화면에 message를 write
    • 입력되는 문자는 화면에 표시된다.
  • GUI에서 아이콘이 표시되고 사용자가 소스파일을 선택할 때
  • 입력을 읽을 때
• 두 파일을 open 하는 경우에 사용되는 시스템 콜
  • 에러 : 파일이 존재하지 않거나 접근권한 오류
  • 에러가 발생하고, 에러 나면 에러내용을 표시하고, 에러를 종료시키는 것
• 데이터를 복사해서 Destination file에 write 
• 두 파일 닫기
• 전송 완료 메시지 표시, 프로그램 종료

 

시스템 콜들은 간단한 작업에도 많이 사용된다.

-> 시스템콜은 1초에 몇천 개 호출된다. -> 속도가 빠르기 때문이다.

 

프로그래머들은 API를 이용해서 시스템콜을 간접적으로 사용한다.

• API(Application Programming Interface) : 라이브러리와 함수의 집합
  • Windows API, POSIX API, JAVA API(libc를 사용)
  • API끼리 계층을 이루기도 한다. [상위 API, 하위 API 존재]
• libc : c library for UNIX/LINUX environment

프로그래머들은 왜 직접적인 방법이 아닌 API를 이용해서 시스템콜을 간접적으로 호출할까요?

• 시스템콜을 직접적으로 사용하는 것은 어렵습니다.
  • 각 레지스터에 들어있는 값들을 모두 정확히 알고 있어야 직접 호출이 가능하기 때문입니다.
• API는 사람이 봤을 때 사용하기 편하게 이루어져 있습니다.
  버퍼링 같은 부가적인 서비스들을 제공하므로, 프로그래머 입장에서는 API 쓰는 게 훨씬 편합니다.
• Portability(이식성)
  • 컴퓨터마다 전혀 다른 내부 시스템 구조를 가지고 있더라도, 우리는 API를 기준으로 짜 놨기 때문에 
    그대로 동작한다.
  • 컴퓨터에 맞게 프로그램을 수정할 필요가 없다.

System Call Interface

시스템 호출 인터페이스 : 시스템 호출에 연결하는 라이브러리 함수 집합

User program이 System call을 부르는 과정

1. User program(libc 등도 포함)이 open()등 System call을 호출한다.
2. System Call interface에서 핸들링. User mode -> Kernel mode로 전환
3. System call function pointer에서 sys_open()등 함수 호출, 작업 수행
4. 다시 System Call interface로 넘어가서, Kernel mode -> User mode로 전환

Caller

• 시스템 콜이 어떻게 구현되어 있는지 알 필요 없다.
• 단순하게 시스템 콜 이름, 파라미터, 무엇을 리턴하는지만 알면 된다.

 

System Call Types

 

Process control(프로세스 제어)

• fork, exec, exit...
• 프로세스의 생성/종료, 메모리 할당/해제, 등등등 OS는 프로세스들을 관리해야 한다.

예시 시나리오

• Error Handling
  • 종료하기 위해서는 다음과 같은 과정이 필요하다.
    • Memory dump를 만든다.
    • 메시지를 출력한다.
    • 다음 실행할 명령어를 결정하고, 실행한다.
• 다른 프로그램 로딩, 실행
  • 새로운 프로세스가 종료되면 어디로 Control을 넘겨줘야 할지 결정해야 한다.
  • Concurrently 하게 기존 프로그램과 다른 프로그램을 실행해야 할지에 대한 여부를 결정해야 한다.
• Multiprogramming에서도 프로세스들을 관리해야 한다.
  • 프로세스 Attributes들을 get/set(Priority, Time limit)
  • OS는 공유된 데이터를 찾기 위한 시스템 콜을 제공해 준다.
  • 필요 없는 프로세스들을 선택적으로 종료해야 한다.

File manipulation(파일 관리)

• create, open, close, read, write, lseek

Device manipulation(장치 관리)

• open, close, read, write, ioctl

Information maintenance(정보 유지)

• time, date , pid

Protection(보호)

• chmod, umask , chown

Communications(통신)

• open, close, connect, accept , read, write , 등등,,,
• 네트워킹, 소켓 프로그래밍 등..
• 커뮤니케이션에는 두 가지 모델(접근, 구현)이 있다.
  1. Message Passing
     • 한 프로세스가 다른 프로세스에게 메시지 전달.
     • Connection이 처음에 먼저 열려있어야 한다.
     • 프로세스는 메시지 전송 요청만 하고, 실제 전달은 OS에 의해 완료된다.
     • 장점
       • Os가 전달해주기 때문에 동기화 문제 X
     • 단점
       • 성능이 다소 떨어진다.
  2. Shared-memory :
     • 기본적으로, 프로세스는 다른 프로세스의 메모리 공간에 접근할 수 없다.
     • 공통으로 사용하는 메모리 공간을 만들고, 서로 공간을 공유한다.
     • 프로세스들은 OS에게 시스템 콜로 Shared memory 접근 요청을 보내고, OS가 이를 받아 프로세스들에게 알린다.
     • 장점
       • 성능이 좋음
     • 단점
       • 동기화 문제. 각 프로세스들이 언제 메모리에 접근할지 모른다.

OS Design and Implementation

 

OS 설계의 목표 : 2가지로 나뉨.

1. 사용자 관점
   1. 사용이 쉬워야 하며, 신뢰할 수 있어야 하고, 배우기 쉬워야 하고, 빨라야 한다.
2. 시스템 관점
   1. 구현이 쉬워야 하나도. 관리, 유지가 쉬워야 하고, 작동이 쉬워야 하고, Flexible 하고, 효율적이어야 하며, 빨라야 한다.
3. 막연한 요구사항일 뿐, 분명한 해결책은 없다.

지침

1. 메커니즘과 정책을분리 -> OS 설계를 더 모듈화 할 수 있다.
   1. 매커니즘 : 무엇을 어떻게 할 것인가?
   2. 정책 : 무엇이 되게 할 것인가?
2. 예시 : 비밀 먼 호를 한 달마다 주기적으로 바꿔주는 것,
3. 정책의 변경이 메커니즘의 변경을 필요로 한다면, 바람직한 설계가 아니다.

 

OS implementation

 

어셈블리어로 구현

-> 재미없고, 어렵고, 에러 나기 쉽고, 이식하기 어렵다.

 

High-level language로 구현한 경우

• 장점
  • 구현이 빠르다.
  • 이해하고 디버그 하기 쉽다.
  • 컴파일러의 성능이 개선되어서 개선된 코드가 생성된다.
  • 이식하기 쉽다.
• 단점
  • 성능적인 면 : 최적이 아닌 코드가 생성될 가능성이 있다.
    • 복잡한 Dependencies를 다루기에는 컴파일러를 사용하는 것이 좋다.
  • Compromise(타협)
    • 치명적인 코드들은 우선 High-level-language로 작성한 후, 최적화된 코드로 대체할 수 있다.

Operating System Structure

Monolithic structure(단일구조)

• 애플리케이션 및 모든 커널 서비스들이 같은 주소 공간에 위치하기 때문에, 각 컴포넌트 간의 커뮤니케이션이 비교적 효율적이다.
• 하지만 어느 한 부분이 수정되면 전체를 다시 컴파일해야 하고, 한 컴포넌트에서 발생한 문제가 전체 시스템의 문제가 될 가능성이 크다.

Monolithic Structure

 

Coomponentized, Modularized approach

• Component(Module) : Input, Ouput, functions로 구성되어 있는 시스템의 일부

 

Simple Structure

• 운영체제는 처음에 소형이면서, 간단하고, 제한된 시스템으로 시작되었다.
  • MS-DOS
    • 인터페이스와 기능 계층이 잘 분리되어 있지 않다.
      • Application이 입출력 루틴에 직접 접근할 수 있었다.
      • 이러한 자유는 프로그램을 취약하게 만들었다.
    • 하지만 Application에 문제가 생기면, 전체 시스템에 문제가 생겼다.
  • Original Unix
    • UNIX는 커널과 시스템 프로그램으로 구성되어 있는데,
      커널은 인터페이스 + 장치 드라이버로 다시 분리
    • 시스템 인터페이스 아래와 물리적 하드웨어 위의 모든 것이 kernel이다.
    • Monolithic(단일) 구조를 형성했는데, 구현하기 어렵고, 유지 보수 하기 어렵다.

Layered Approach(계층적 접근)

•  OS가 여러 개의 계층으로 나뉨.
  • 최하층[layer 0] : 하드웨어
  • Layer N(최상위 계층) : User Interface
• 하나의 레이어는 인접한 레이어끼리만 통신한다.
  • 상위 레이어는 하위 레이어의 작업을 수행시키고, 
    하위 레이어는 상위 레이어에서 Call 할 수 있는 작업을 제공한다.
• 장점
  • 구현이 간단하다. -> 디버깅이 쉽다.
    • 레이어들은 단지 자신의 바로 하위 레이어의 작업만 수행할 수 있음.
    • 최하의 계층부터 디버깅하닥, 어느 계층에서 오류가 발생하면 그 계층만 다시 디버깅하면 됨.
• 단점 
  • 레이어를 정의하는 것은 어렵다.
    • OS의 어느 부분이 어느 레이어에 들어가야 하는지 명확히 정의할 수 없다.
  • 효율성이 낮다.
    • 레이어들을 거치는 과정이 오버헤드를 야기할 수 있다.

Microkernels

• 핵심 아이디어
  • 커널을 최소화하자.
  • 필수적이지 않은 함수들은 User-level library로 구현하자.
    •  필수가 아닌 함수를 커널에서 유저로 이동하여 커널을 다순화 시킴.
• 주요 기능
  • 사용자프로그램과 사용자 공간에서 수행되는 다양한 서비스들 간의 효율적인 통신을 제공해 준다.
    
    • 직접 상호 작용을 하지 않고 마이크로커널과 메시지를 교환함으로써 통신한다.
• 장점 
  • OS kernel 확장 가능
  • 다른 하드웨어로 이식이 쉽다.
    • 커널은 작고 간단하기 때문이다.
  • 높은 보안성과 신뢰성을 제공한다.
    • 커널은 간단하기에 유지하기가 쉽다.
  • 서비스가 잘못되더라도 운영체제의 다른 부분은 영향을 받지 않는다.
• 단점
  • 가중된 시스템 기능 -> 오버헤드 때문에 성능이 감소된다.
    • Context switching, System function call의 오버헤드