March 21, 2020
참고도서: Operating System Concepts (9/E) Abraham Silberschatz, Peter B. Galvin, Greg Gagne
System call은 운영체제에 있어서 아주 핵심이 되는 요소이다. 어떤 프로세스나 서비스가 실행되기 위해서는 System Call을 통한 컴퓨터 시스템으로의 접근이 필수적이기 때문이다.
프로세스는 system call의 연속이라고 할 수 있다. 우리가 시스템 내의 어떤 파일을 복사하려고 할때, 이름 입력받기, 복사하기, 파일에 접근하기 등 거의 모든 영역에서 system call을 통한 명령 수행이 일어난다.
우리가 앞선 내용에서 배웠던 user mode과 kernel mode의 전환도 이 system call 을 통해서 일어난다.
하지만 대부분의 개발자들은 이런 system call이 언제 무엇을 위해 일어나는지 잘 알지 못한다. 왜냐하면 개발자들은 약속된 프로그래밍 언어를 입력하고 이 문법들에 대한 system call의 호출이 모두 준비되어있기 때문이다. 이런 명세를 Application Programming Interface, 혹은 API라고 한다.
API의 이야기를 조금 더 해보자. System call은 일반적으로 그 종류가 이미 정해져서 어떤 고유한 번호가 할당되어있다. 그리고 해당 번호에 맞는 명령어들이 준비된 테이블에서 인덱싱 되어서 호출된다. system call이 일어났을 때, 테이블에서 명령을 가져와 수행할 수 있도록 해주는 녀석을 System call interface 라고 한다.
System call이 일어날 때, 어떤 system call은 parameter를 필요로 하는 경우가 있다. 이때 이 parameter를 어떻게 전달할지에 대한 일반적인 방법 세가지를 알아보자.
가장 단순한 방법이다. Parameter를 바로 CPU 내의 레지스터로 전달하는 것이다. 그런데 문제는 paramter의 개수가 CPU 내에 있는 레지스터의 개수를 초과할 수 있다는 것이다.
두번째 방법은 Paramter를 일단 메모리나 테이블, 혹은 블럭단위로 저장해두고 해당 메모리 주소를 CPU의 레지스터에 보관하는 방법이다. 리눅스와 솔라리스가 이 방법을 사용한다.
Parameter를 스택개념을 사용하여 Push 하고 Pop 하는 방식으로 CPU의 레지스터에 전달하는 방법도 있다.
일반적으로는 두번째, 메모리 주소를 전달하는 방법과, 세번째, 스택구조로 paramter를 관리하고 전달하는 방식이 사용된다. 왜냐하면 첫번재 방법은 paramter의 갯수에 제한을 받지만 두번째, 세번째 방법은 parameter의 갯수나 길이에 제한이 없기 때문이다.
Sytem call은 여러 상황에 따라 적절하게 사용된다. System call에 어떤 종류가 있는지 확인해보.
System call을 통해 프로세스가 실행되기도 하고 종료되기도 한다. 또한 작업이 진행 중이던 process에서 load 나 execute system call을 통해 새로운 프로세스를 불러오기도 하고 실행시키기도 한다. multitasking system에서는 system call이 process control을 위해 더 자주 사용된다. 어떤 작업이 수행되는 동안 새로운 process를 로드해서 실행시키기도 하고 여러 프로세스에서 하나의 데이터를 한번에 접근하고 수정하는 일을 막기 위해서 공유데이터를 lock 하는 system call 도 존재한다.
파일을 다루는 경우에도 다양한 system call 이 사용된다. 파일의 생성과 삭제, 파일 열기와 닫기, 파일 읽기와 쓰기, 커서위치 변경과 같은 모든 작업들이 system call에 의해 일어난다. 그리고 이 system call들은 단순히 파일을 위한 작업에서 뿐만 아니라 디렉토리를 다루는 작업에서도 일어난다.
System call은 user program에게 정보를 전달하거나 시스템 안에서 일어난는 문제에 대한 정보를 보관하는 데에 사용되기도 한다. user program 에서는 시스템의 시간이나 날짜정보를 요청항때 사용되기도 하고, 디버깅을 위한 목적으로는 운영체제가 모든 프로세스에 대한 실행정보를 가지고 있기 때문에 이 정보들에 접근하기 위해 system call을 사용하기도 한다.
여기서 communication은 process 사이에 일어나는 통신을 의미한다. 프로세스가 서로 통신하게 될 때, 일반적으로 두가지 모델을 통해 통신하게 된다.
이 방법은 말 그대로 process 들이 message 를 교환하는 방법이다. 이 message릉 교환하기 위해서 mailbox라는 것을 사용하게 된다. 서로에게 통신을 요청하거나 접근을 요청하기 위해서 system call이 사용되고 통신을 요청하는 쪽을 client, 그 요청을 받아 message 를 읽고 쓰는 쪽을 server 라고 한다. 보통 이런식으로 연결을 받아들일 때 사용되는 특수한 목적의 process 를 daemon 이라고 한다.
이 방법은 프로세스가 다른 프로세스의 메모리 영역에 대한 접근을 하도록 하는 방식으로 이루어져 있다. 공유 메모리는 이미 다수의 프로세스가 접근하는 것을 허용하도록 동의되어 있어야한다. 왜냐하면, 일반적으로 운영체제는 어떤 프로세스가 다른 프로세스의 메모리에 접근하는 것을 허용하지 않기 때문이다.
대부분의 시스템에서는 두 방법을 모두 구현한다.
Message passing model은 적은량에 데이터를 교환할 때 자주 사용되는데, 적은량의 데이터에서는 충돌이 일어날 상황이 없고 캄퓨터 간의 통신만 사용하면 되기 때문에 메모리를 공유하도록 설계하는 것 보다 구현이 간단하다.
Shared Memory Model은 메모리의 전송 속도를 그대로 사용하기 때문에 네트워크를 사용하는 통신보다 빠르고 편리하게 사용할 수 있다. 하지만 protection 문제와 빠른 메모리 접근에 대한 동기화 문제가 이슈이다.
Protection은 운영체제가 사용자로부터 시스템의 리소스들을 보호하는 것을 말한다. 이것을 위해서 파일의 접근 허가권한을 요청하는 permission() system call이 사용되고 특정 사용자의 리소스 사용을 허가하거나 제한하는 allow/deny_user() system call이 사용되기도 한다.