매우 간단한 프로그램 이라도 운영체제의 기능을 많이 사용한다. system call 은 그러한 운영체제의 기능을 제공하는 것이며 개발자는 이 기능을 쉽게 사용하기 위해 제공되는 API 를 통해서 system call 을 효율적으로 사용한다.
특정 저수준 작업(하드웨어 접근)은 어셈블리 명령을 사용하여 작성되어야 하더라도 호출은 C, C++ 언어로 작성된 함수 형태로 제공된다.
Example
어떻게 사용되는지를 먼저 다룬다.
cp in.txt out.txt
Shell
복사
위의 명령을 예시로 한다.
1.
화면에 prompt 메세지를 작성한다.
•
복사하고자 하는 파일을 선택한다
•
복사 되어서 어디로 가야할지 결과를 입력한다
2.
키보드에서 두 파일의 이름을 읽는다.
3.
UI 에서 파일 이름 메뉴가 창에 표시된다.
4.
마우스를 사용해 대상 이름을 지정한다.
5.
파일이 열린다
6.
안에 들어가 문자열을 한줄 한줄 text가 없을 때까지 읽으며(until read fails) 대상 파일(output)에 쓴다
7.
output file 을 닫는다
8.
쓰는 작업이 완료되었음을 UI에 알린다.
크게 보면 과정이 위와 같지만, 이 과정들 사이사이에 또 다른 system call 이 들어와야 한다.
상세한 system call
Application Programming Interface (응용 프로그래밍 인터페이스) - API
대부분의 프로그램은 운영체제의 기능을 상당히 이용한다. 개발자들은 API 에 따라 프로그램을 설계한다.
API: 각 함수에 전달되어야 할 매개변수들과 프로그래머가 기대할 수 있는 반환값을 포함하여 응용 프로그래머가 사용 가능한 함수의 집합을 명시한다.
OS의 system call 을 이 API 들이 대신해주는데 왜 대신하는 것 일까?
→ 호환성
같은 API 를 지원하는 시스템 이라면 어떤 시스템이건 관계 없이 동일하게 compile 될 것임을 기대할 수 있다.(물론 현실은..) 그리고 system call 은 호출이 복잡하고 상세한 설명이 필요한데 이러한 지점을 API 문서가 해결해준다.
system call
RTE(Real time Enterprise)
•
System call 을 처리하는데 중요한것이 RTE(Real Time Enterprise: 실시간 환경) 이다.
•
RTE는 System call interface 를 제공한다.
•
API 호출을 가로채 필요한 운영체제 system call 을 부른다.
•
system call 에 번호가 할당되고, 이 번호로 색인이 되어 찾기 쉽게 된다.
•
이러한 과정 때문에 호출자는 API만 준수하면 되고 운영체제가 내부적으로 무엇을 하는지 몰라도 된다.
RTE? 운영체제가 제공하는 system call 에 대한 연결고리 역할, system call interface 를 제공한다.
이 RTE 가 관리하는 system call interface 를 통해 운영체제의 동작은 캡슐화 되고 호출하는 application 등은 운영체제가 무엇을 하고 어떠한 값을 return 하는지만 알면 된다. (내부적으로 자세한 것은 알 필요가 없다)
운영체제에 param 을 전달하는 방법은 3가지 이다.
1.
register 를 통해 전달한다 (단 param 의 갯수에 제한이 있어 5개 이하)
2.
메모리 내의 블록이나 테이블에 저장 (5개이상)
3.
stack 에 넣어 전달
2, 3 번은 param 의 갯수에 제한이 없어 특정 운영체제에서 선호된다.
Types of System calls (시스템 콜의 유형)
유형은 크게 5가지로 나뉜다.
1. 프로세스 제어
C표준 라이브러리 예시
한 프로그램이 다른 프로그램을 실행시켰다.
load 된 새로운 프로그램이 종료되면 제어권은 어디로 가는가? (실행시킨 프로그램은 어떻게 되는가?)
•
제어권을 기존(실행시킨 program)으로 돌려준다
◦
기존 program의 메모리 이미지를 보관하고 있어야 한다.
•
병행하여 실행한다(다중 programming)
◦
system call create_process() 를 실행시킨다
◦
새로운 프로세스를 실행 시켰으니 제어권을 가져야 한다
▪
job, process 의 속성을 결정하고, reset 할 기능이 필요하다.
▪
job, process 를 종료 시킬 수 있는 기능도 필요하다.
◦
실행시킨 특정 event 가 종료되길 기다릴 수도 있다.
서로 다른 프로세스 간 data 를 공유한다.
•
데이터를 공유한다면 공유 데이터의 일관성을 보장 하기 위해 잠금(lock) 기능이 필요하다
•
Locked 상태이면 어떤 process 도 접근이 불가능해야 한다.
•
system call acquire_lock() , release_lock() 이 제공된다.
Single tasking, Multi tasking
process 제어에 대해 효율적으로 설명하기 위해 single tasking 과 multi tasking 으로 분류하여 설명한다.
single tasking
아두이노를 사용해 예를 들어 설명한다
•
아두이노는 한번에 하나의 프로그램(sketch)만을 Boot loader 를 통해 메모리에 올릴 수 있다.
•
다른 스케치를 실행하고자 한다면 메모리에 적재된 sketch 를 대체해야 한다.
(다수의 프로그램을 실행하는 FreeBSD)
Multi tasking
FreeBSD 로 예를 들어 설명한다.
1.
사용자가 로그인 할 때 선택된 shell 이 수행되면서 명령을 기다린다.
2.
multi tasking 이기 때문에 command interpreter 는 다른 프로그램이 실행되는 동안 수행을 계속한다.
3.
새로운 프로세스를 시작하기 위해 fork() system call 을 호출한다.
4.
선택된 명령이 exec() system call 로 메모리에 적재된다.
5.
프로그램 수행
6.
명령에 따라 종료를 기대하거나, 백그라운드에서 실행된다.
•
background 에서 실행되는 process 는 UI를 통해 명령을 받을 수 없다.
•
shell 이 그 자원을 사용하고 있기 때문이다.
7.
shell 은 다른 명령을 입력받거나, 다른 프로그램을 실행 하게 할 수 있다.
8.
process 가 끝나면 system call exit() 를 수행한다.
•
상태 코드 0을 반환하거나
•
그 외의 오류 코드를 반환한다.
2. File Management 파일 관리
13~15 에서 더 자세하게 논의된다.
•
create(), delete() 가 필수이다.
•
open(), read(), write(), reposition() , rewind()
•
파일을 더이상 사용하지 않을 때 호출하는 close() 도 필요하다.
•
어떠한 속성을 설정하고 reset 도 할 수 있어야 한다.
3. Device Management
process 는 작업을 계속 수행하기 위해 추가 자원이 필요할 수 있다.
•
추가 자원: ram, disk drive, file 접근 등이 될 수 있다.
이 자원들이 할당되어 제어가 사용자 프로그램으로 복귀되고 그렇지 않으면 자원이 할당될 때 까지 대기한다.
운영체제에서 제어하는 다양한 자원들은 장치로 간주된다.
•
물리적 자원: 디스크 드라이브
•
추상적(혹은 가상적) 자원: 예를 들어 파일
다수의 사용자가 하나의 device 에 대해 독점적인 사용권을 보장받기 위해 다음의 순서가 필요하다.
1.
사용을 위해 request()
2.
장치를 읽는다 read()
3.
장치에 필요하면 쓰기 작업이 발생한다 write()
4.
위치가 변경될 수 있다 reposition()
5.
사용이 종료되면 release() 로 방출한다.
여러 특징이 File 과 비슷하여 file device structure 로 결합했다.
그 안에 숨겨진 system call 이 다르더라도 UI를 이용하여 파일과 장치를 비슷한 것 처럼 만들수도 있다.
Information maintenance(정보 유지 관리)
많은 시스템 콜은 사용자 프로그램과 운영체제 간의 정보 전달을 위해 존재한다.
제공하는 system call 카테고리
•
시간
•
시스템에 관한 정보
◦
버젼, 자유 메모리, 자유 디스크 공간 등등..
•
디버깅 여기에 dump() 가 있다.
•
운영되고 있는 모든 프로세스에 관한 정보와 이 프로세스에 접근하는 system call
Communication (통신)
message 전달과 공유 메모리의 두 가지 일반적인 모델이 있다.
•
message 전달
◦
통신하는 두 process 가 정보를 교환하는데 필요하다.
◦
네트워크에서는 host 이름을 알듯이 process 에서는 process 이름을 알아야 한다.
▪
ex) pid
•
공유 메모리
◦
OS의 정상적인 상황에서 하나의 process 가 다른 process 의 memory 에 접근하는 것을 막으려고 한다. 공유 메모리는 이러한 제한을 제거하는 데 동의할 것을 필요로 한다.
◦
공유 자원은 공유 되는 데이터가 오염되거나 의도치 않게 삭제되지 않는 것이 중요하다
▪
프로세스는 동일한 위치에 동시에 쓰지 않도록 보장할 책임을 진다.
◦
공유한 메모리에 정보를 쓰고, 저장하고, 읽으면서 정보를 공유하기 위한 목적.
◦
shared_memory_create(), shared_memory_attach() system call 을 사용한다.
메세지 전달은 소량의 데이터를 교환할 때 유용하다. 피해야 할 충돌이 없기 때문이다.
OS 에서 반복적으로 만나는 내용은 open, close 이다. file을 읽을때도 open, close 가 있고, 프로세스와 프로스세 혹은 네트워크 통신에도 이 개념이 들어가 있다.
구현 관점에서 message 전달이 더 쉽게 구현할 수 있다.
성능 관점에서 공유 메모리가 뛰어나지만, 보호와 동기화 부분에서 여러 문제점을 가지고 있다.
Protection (보호)
컴퓨터 시스템이 제공하는 자원에 대한 접근을 제어하기 위한 기법을 지원한다.
요즘은 networking, internet 의 출현으로 서버에서 휴대용 device 까지 보호의 개념을 고려해야한다.
이런 개념은 permission 과 연관이 있으며 set_permission(), get_permission() 의 system call 을 통해 관리되며, allow_user(), deny_user() 를 통해 특정 사용자에게 접근이 허가 혹은 불허 되었는지 명시한다.
