[OS / 운영체제] Command Line Interpreter, Programming Interfaces, Dual Mode Operation, Dual Mode Operation, System call, Process Control: Load/Execution, FreeBSD Unix, MS-DOS, Device Management, System Programs

Operating System Services

 

 

 

Command Line Interpreter

putty, xterm, MacOS terminal을 많이 사용한다. 초보자들한테는 많이 불편할 수 있지만 개발자 입장에서 많이 사용되고 있다.

 

 

Programming Interfaces

운영체제가 제공하는 가장 기본적인 Interface는 System call이다. POSIX IO call에는 다음과 같은 call들이 있다. 파일을 열고 읽고 쓰고 닫는 역할을 한다. User Interfaces는 파일을 읽을 수 있다. System call은 Interrupt에 의해서 call 된다. 보통 사용하는 high level language는 Interrupt를 직접적으로 발생시킬 수 없다. 그 사이를 연결하는 Bridge 역할이 필요한데 그게 System call Interface의 역할이다. POSIX에 대한 소개가 있다. UNIX의 Standard이다. Linux 는 공식적으로 POSIX 인정을 받지는 않지만 Unix 의 Implementation이라고 인정받고 있다.

 

System call

Function call과 유사한 점이 있다. Application program이 Usermode에 돌아가고 있다고 가정한다. Device를 Access해야 하는 경우 그 권한이 없어서 kernel에 요청을 하게 된다. Kernel은 Device에 접근하기 위한 모든 권한이 있다. 일반적인 Function call과 다른 것은 Interrupt 메커니즘으로 이루어진다는 것이다. Interrupt handler로 jump를 하게 되고 이는 kernel 안에 위치한 안전하고 검증된 코드이다. C C++로 작성되어 있어서 속도 또한 빠른 특징이 있다. 어째서 System call은 Interrupt call이라는 복잡한 메커니즘을 사용하는 것일까? 안전하게 Kernel mode로 전환하기 위한 방어 체재라고 할 수 있다.

 

Dual Mode Operation

하나는 User mode이고 하나는 kernel mode이다. OS 서비스가 필요하면 kernel에 도움을 요청하고 Kernel service를 제공하기 위한 kernel mode를 실행하게 된다. usermode에서 kernel mode로 전환을 할때 preveledge가 낮은 mode에서 높은 mode로 변환되는 타이밍인데 만약 이런 전환이 아무 제약없이 쉽게 이루어진다면 user와 kernel을 구분할 필요성이 없어지게 된다. 여기서 필요한 것이 Interrupt 메커니즘이다. 위험한 동작을 다 막을 수 있어야 한다. Interrupt를 날리는 순간 Interrupt handler로 제약권이 넘어가게 되고 Kernel안에 존재하며 안전하다. Interrupt vector라는 Table이 관여하게 된다. jump할 수 있는 목적지는 Interrupt handler로 국한되게 된다. Kernel mode로 돌아갈 때 안전한 코드만을 실행할 수 있도록 만들어준다. 다시 user mode로 돌아오게 될때 높은 Preveldge에서 낮은 곳으로 이동이여서 별 문제가 발생하지 않는다.

 

Parameter Passing in System call

Function에는 parameter가 있다. System call에도 마찬가지이다. 가장 간단한 방법은 래지스터를 사용하는 것이다. 래지스터에 값을 가지고 Interrupt를 발생시키고 Handler가 그 값을 가지고 처리를 해주는 것이다. 정보가 작을 때 주로 사용할 수 있다. 정보가 커지게 되면 주소값을 넘기는 방법 또한 존재하고, System stack을 사용할 수 있다. Fucntion call parameter local variable을 사용할 때 만들어진다.

 

 

Example

file을 Copy하는 프로그램을 생각해보자. A에서 B로 카피한다고 생각해보자. srcFile과 destFile을 읽어야 한다. 그리고 파일을 열고 생성한후 Read와 Writhe를 진행한다. close를 하게 된다. 이 과정에 user에서 파일의 이름을 물어본다면 IO Device를 사용하게 된다. User에게 파일 이름을 작성하세요 라는 것도 OS를 통해서 할 수 있고 System call에 의해서 작동하게 된다. 전부 다 OS의 System call이 작동하게 된다. 사실상 굉장히 많은 OS의 System call이 발생하고 있었다.

 

System call Interface

open이라는 function을 생각해보자. open은 kernel의 기능이 필요하고 kernel의 기능은 system call로 제공되고 system call은 Interrupt로 제공된다. High level language는 function의 형태로 제공된다는 것이다. 누군가가 Function call Interface와 OS가 제공하는 Interrupt driven Interface의 연결고리가 필요하다. 그것이 System call Interface 이다. 그림에서 Interrupt vector라는 파란색 상자가 보인다. 

 

 

System call Interface

왼쪽은 user의 code이다. 이 코드에서 Open이라는 function을 call하게 도니다. open은 System call Interface 안에 있는 function call이다. 내부에는 어샘블리 코드를 포함하고 있다. C언어 안에 어셈블리 코드가 있는 것을 in-line assembly code라고 한다. 첫 번째 명령어는 5라는 숫자를 eax라는 래지스터에 집어넣라는 것이다. int 0x80으로 되어있다. 어셈블리어에서는 int는 Interrupt를 발생시키라는 것이다. 80번의 Interrupt를 발생시키라는 것이다. Linux의 모든 종류의 Interrupt는 80번을 통해서 서비스가 되게 되어있다.  System call과 무관하게 interrupt 80번을 통과해야 System call을 할 수 있게 된다. open의 경우 5번이 지정되어 있다. System call 번호를 래지스터에 집어넣고 80번 Interrupt를 호출하게 된다. 그 제어가 interrupt Handler로 제어권이 넘어가게 되고 80번 Entry로 넘어가게 된다. 80번 Handler가Interrupt Handler이고 eax 래지스터의 값을 참조한다. 실제 그 open을 처리해줄 함수를 호출하게 된다. sys_open이라는 실제 open을 하게 해주는 function이다. mode 전환은 Interrupt를 발생시키는 순간 전환된다. sys_open은 kernel mode에서 이루어진다. 동작이 끝나면 Interrupt return 메커니즘에 이해서 open function으로 돌아오고 다시 user의 open 코드로 돌아오게 된다.

 

System call Interface

80번 리눅스에 의해서 사용된다. System call을 실제로 처리해줄 Handler를 알기 위해서 System call table이 존재한다. Interrupt vector table과 구분된다. 80번 Interrupt가 발생하면 Interrupt vector를 참조해서 80번 Interrupt를 찾아서 jump하게 된다. 80번 handler가 시작되면 지금 내가 실행해야 하는 System call이 무엇인지 알기 위해서 System call handler가 저장되어 있는 table을 살펴야 한다. 그 Index System call Number가 된다. 이전에 래지스터에 담긴 5라는 숫자에 대응한다. User 입장에서 System call Interface가
일반 적인 function call과 별 다름이 없어 보인다. 

 

 

System-call Interface

System call을 호출할 때 전달해야 하는 정보를 전달하는 역할을 한다. User mode에서 kernel mode로 스위칭을 한다. Interrupt를 발생시키는 순간 전환이 된다. 필요한 데이터 처리와 전환하기 위해 준비해야 할 것들이 있다면 System call Interface가 처리를 한다. read와 fread의 차이점은?? read는 OS가 제공하는 System call이다. fread는 C 언어가 제공하는 함수이다. C언어는 특정된 OS에 종속되면 안되므로 여러 OS가 제공하는 공통적인 기능을 모아서 통일되게 모은 것이 Standard function이다. 보통 OS와 무관하게 사용할 수 있다. 여러 OS를 작동하게 할 코드를 작성하는 경우 fread를 사용하는 것이 좋다.

 

 

API

OS나 library나 application이 자기의 기능을 서비스로 제공하기 위해 정해놓은 Interface를 의미한다. Windows의 경우 system call과 API를 구분하는 경향이 있다. API는 System call을 조합해서 만든 더 High level feature이다. 예를 들어 MessageBox function이 API에 해당한다. 바닥에 Primitive한 System call이 있고 조합을 해서 API라는 high level feature를 제공한다. 

 

 

Example of API

window에 있는 API function이 있다. 

 

 

Example of System call

윈도우

CreateProcess라는 것은 Unix의 fork함수에 대응한다. 

 

 

Process Control: Load/Execution

프로그램을 실행할 때 마우스로 더블 클릭을 한다. 그 과정에 OS가 개입된다. 예를 들어 User가 더블 클릭을 하면 Interrupt가 발생하고 Interrupt Handler로 점프하게 되고 마우스라고 인식을 하며 Handler를 처리하게 된다. 사용자가 프로그램을 실행하고자 하는 구나를 파악하며 OS가 그 프로그램을 시행하는 것이다. 마지막에 프로그램을 시행하는 주체는 OS가 된다는 것이다. CLI 로 돌리게 되는 경우 CLI에 새로운 Child Process를 만드는 Parent 역할을 한다. Process Creation 역할을 한다. Child Process 만들어지는 동안 Parent가 무슨 역할을 하는가? CHild가 실행될 때 Parent Proecss가 대체되는 경우 소실된다고 말할 수 있다.

 두 번째의 경우 기다린다고 말하는 것이다. CLI가 pause 된다. Parent Process가 Child Process와 병렬 처리 되는 경우이다. MacOS Finder의 경우 실행을 멈추지 않고 같이 실행되는 것이다.

 

 

MS-DOS

Single tasking program이다. booting 이 끝나면 kernel이 가장 낮은 address mode에 위치하게 된다. 사용자가 특정 프로그램을 실행시키면 그 프로그램이 메모리에 로드가 되고 실행이 된다. Command Interpreter를 overwrite하게 되는 문제가 발생한다. 이런 꼼수의 기술을 사용했다.

 

 

FreeBSD Unix

Booting을 하고 메모리를 살펴보면 모두가 다 대등한 지위를 가지고 있다. Unix에서는 Commend line Interpreter를 내가 원하는 버전으로 선택할 수 있다. Command Line Interpreter가 kernel의 일부가 독립된 Userlevel의 프로그램이어서 가능한 것이었다. 많은 경우에 CLI에서 실행시킨다. shell에 프로그램을 입력을 하면 fork라는 시스템 콜을 호출한다. 프로세스를 실행하는 명령어이다. Parent Process와 거의 똑같이 생긴 Child Process를 생성시킨다. 왜 복사판을 만드는가?

사실 Unix에서 새로운 Process를 쉽게 만들 수 있는 방법은 Parent Process를 복사하는 것이다. 구현 상에서 많은 프로그램 코드가 요구되기 때문에 이 방법을 사용한다. Child Process를 내가 원하는 프로그램을 대체를 해야 한다. exec이라는 시스템 콜이 그역할을 한다. 현재의 프로세스를 새로운 프로그램으로 대체한다. 초기에는 CLI였는데 exec를 통해 원하는 프로그램으로 바뀌게 된다. 먼저 fork를 하면 wait이라는 function call을 통해 현재 있는 상태로 기다리라는 명령을 하게 되고 child process가 종료될 때까지 기다리게 된다. child가 exec에 의해서 새로운 프로그램으로 대체되고 그 프로그램이 돌아가는 동안 Parent process는 멈춰있게 된다. exit을 통해서 종료하게 되면 다시 Parent Process가 동작하게 된다. CLI Interpreter의 역할이다. 동시에 병렬적으로 돌아가게 할 수 있다. Wait System call을 하지 않으면 된다. 원래 fork를 호출한 Parent process가 멈추지 않고 병렬적으로 돌아가게 된다. 

 

Process Control: Load Execution

Process가 Process를 control 할 수 있다. Max execution time을 하거나 멈춘다거나의 동작을 할 수 있다. 무한히 기다릴 수도 있고 정해진 시간동안 기다릴 수 있다. Event를 Parent한테 전하는 순간까지 기다리게 할 수 있다.

 

Debugging

디버깅 다하는 프로그램이 한 Statement씩 되도록 지정할 수 있다. 특정한 영역만 실행시키고 다시 parent로 제어권이 돌아오는 등의 반복을 할 수 있다. 

 

 

Termination

Normal Termination, 에러 없이 정상적으로 종료하는 과정. 유지하기 위해서 할당했던 Resource를 deallocation을 하는 것이 중요하다. 회수하고 이 프로세스가 열어놓은 파일을 close를 한다. 

반면 비정상종료의 경우 다르다. User가 원하는 상황이 아니기에 추가적인 역할을 할 수 있다. 현재 상황을 dump 해버리는 상황일 수도 있다. 따라사 나중에 그 상황을 분석하기 위해 정보를 남겨놓는 과정이라고 볼 수 있다.

 

 

File Management

Create하고 Delete/  Read write repotion / Get set file / Directory Operation / More service
ls라는 명령어. OS의 kernel이 아니고 별도의 ls라는 프로그램이 있다. 이렇게 API나 System call을 통해서 OS가 직접하는 경우도 있지만 다른 프로그램에 의해서 File management를 제공하는 경우도 있다.

 

 

Device Management

사용권을 전달할 때 독점적인 권한을 부여해야 하는 경우가 있다. 만약 다른 프로세스가 사용중에 있는 Resource를 사용하고 싶을 때는 wait를 하게 한다. Resource allocation이라고 한다. 그 리소스에 Read와 Write operation을 할 수 있다. 사용 후 반납을 하는데 Release라고 한다.

 

Device Management

file 뿐만 아니라 network와 printer에 각각 read와 write를 할 수 있다. 실제 파일이 아닌 여러 Device를 가상의 환경인 것처럼 Device를 만들 수 있다는 것이다. Consistence가 좋아지고 동일한 flow의 사용을 하게 할 수 있다.

 

Information Maintenance

 

 

System Programs

기본적으로 User mode에서 동작하는 일반적인 Application program이다. 구체적인 task를 위해서 만들어진 것이라기 보다 환경을 제공하는 것이라고 이해해야 한다.