OS ) 시스템 콜

시스템 콜

운영체제에 의해 사용 가능하게 된 서비스에 대한 인터페이스 제공

• 일반적으로 하드웨어를 직접 접근하는 시스템 콜은, C 와 C++ 언어를 이용한 함수 형태로 제공된다.

예제 ) 파일 데이터 읽어서 다른 파일로 복사하기

• 프로그램이 필요한 첫 번째 입력은 두 개의 파일, 즉 “입력 파일”과 “출력 파일”의 이름일 것.
  • 명령의 일부로 두 파일 이름을 전달하는 것일 텐데..

# 이 명령은 입력 파일 in.txt 를 출력 파일 out.txt 에 복사한다.
cp in.txt out.txt

• 두 번째 입력은 프로그램이 사용자에게 이름을 요청하는 것.
• 대화형 시스템에서는 시스템 콜이 필요할 것이다.
  • 예) 화면에 프롬프트 메시지를 작성하고 키보드에서 두 파일 이름을 지정하는 문자를 읽고, 마우스나 아이콘 기반 시스템에서 파일 이름 메뉴를 창에 표시하고, 마우스 기반으로 소스 이름을 선택하고….
  • I/O 시스템 콜을 이용할 것이다.

시스템 콜

• 프로그램이 입력 파일을 오픈한 후, 출력 파일을 생성하고 오픈하는 것은 각각 시스템 콜이 필요하다.
• 물론, 오류가 발생하면 처리되어야 한다.

시스템콜 종류 예시

• 에러 메시지 출력
• 비정상적으로 종료
• 프로그램을 중단
• 기존 파일을 삭제
• 새로운 파일을 생성
• 기존의 파일을 대체할 것인지, 혹은 프로그램을 중단할 것인지 사용자에게 물어봄.

💡패리티 오류: 하드웨어 오류

응용 프로그래밍 인터페이스 API

API 는 각 함수에 전달되어야 할 매개변수들과 프로그래머가 기대할 수 있는 반환 값을 포함하여 응용 프로그래머가 사용 가능한 함수의 집합을 명시한다.

• 프로그래머는 운영체제가 제공하는 코드의 라이브러리를 통해 API를 활용한다.
  • 모든 운영체제는 고유의 시스템 콜 이름이 있다.
  • Linux 에서는 C 언어로 작성된 프로그램을 위해 제공되는 API 가 있다 → libc
• API를 구성하는 함수들은 개발자를 대신해 시스템콜을 요청한다.

왜 운영체제는 직접 시스템콜을 부르는 것보다 API에 따라 프로그래밍하는 것을 선호할까?

1. 프로그램의 호환성
   • 자신의 프로그램이 같은 API 를 제공하는 어느 시스템에서건 컴파일 됨을 원함.
   • 게다가 시스템콜을 직접 사용하는 것이 프로그래머가 사용하는 API 보다 어렵다.
2. 실행 시간 환경(RTE Runtime Envirenment)
   • RTE 가 운영체제가 제공하는 시스템 콜에 대한 인터페이스를 제공.
   • 시스템 콜 인터페이스가 API 함수의 호출을 가로채 운영체제 시스템 콜을 부른다.
   • 그래서 호출자는 시스템 콜이 어떻게 구현되는지 알 필요 없고, API 만 준수하고 운영체제가 뭘 할 것인지만 이해하면 된다.
   → 운영체제 인터페이스의 대한 자세한 내용은 API 에 의해 개발자로부터 숨겨지고 RTE 에 의해 관리 된다.

원하는 시스템 콜보다 더 많은 정보를 요구할 때

• 예) 입력을 받아들이기 위해 입력으로 사용될 파일이나 장치와 함께 읽어들일 데이터를 저장할 메모리 주소와 길이를 명시하기.
  • 장치나 파일, 길이는 시스템 콜에 대해 암묵적일 수 있음.

운영체제가 매개변수를 전달하기 위한 방법

1. 매개변수를 레지스터 내에 전달 ← 가장 간단
2. 메모리 내의 블록이나 테이블에 저장하고, 블록의 주소가 레지스터 내에 매개변수로 전달 됨 ← 레지스터보다 더 많은 매개변수가 있을 경우
   • 함수 호출 매개변수가 5개 이상.
     • DB 쿼리 매개변수가 5개 이상일 때 등등
   • 대규모 배열이나 객체
3. 5개 이하의 변수는 레지스터, 5개 이하는 블록 ← Linux
   • 프로그램에 의해 스택에 푸쉬되고, 운영체제에 의해 팝 오프 된다.

💡일부 운영체제는 블록이나 스택을 선호한다. 전달되는 매개변수의 길이를 제한하지 않기 때문이다.

시스템콜의 유형

• 프로세스 제어
• 파일 조작
• 장치 조작
• 정보 유지 보수
• 통신과 보호

프로세스 제어

실행중인 프로그램을 수행을 정상적(end())으로 또는 비정상적(abort())으로 멈출 수 있어야 한다.

비정상적인 중지

시스템 콜이 호출되거나 프로그램에 문제가 발생해 오류 트랩(trap)이 유발할 경우, 때때로 **메모리 덤프**가 진행되고 오류메시지가 생성 된다.

• 덤프는 문제 원일을 찾기 위해 특별한 로그 파일이나 디스크에 기록하여 디버거에 의해 검사된다.
• 대화식 시스템에서는 명령 인터프리터가 단순히 다음 명령을 계속 수행하고 사용자가 오류에 응답하는 적절한 명령을 내릴 것을 가정한다.
• 오류 수준을 정의하기 원한다면 더 높은 등급의 오류 매개변수를 전달해서 더 치명적인 오류를 나타낼 수 있다.
  • 정상종료 0등급
  • 비정상 1 이상 등급

적재된 프로그램이 종료되었을 때 어디로 제어를 되돌려줄까?

기존프로그램이 유실될지, 보관될지, 새로운프로그램과 병행하게 실행을 계속하도록 허용할지 결정해야 함.

• 제어가 기존 시스템에 되돌아간다면
  • 기존 프로그램의 메모리 이미지를 보관. → 한 프로그램이 다른 프로그램을 호출 함. (시스템콜)

프로세스 스케쥴링

태스크의 우선 순위, 최대 허용 실행 시간 등을 포함하여 태스크 또는 프로세스의 속성들을 결정하고 재설정해야 한다.

• 새로운 프로세스를 생성한 후, 실행이 끝나길 기다린다.
• 일정 시간만큼 기다릴 수도 있다. (wait_time())
• 특정 이벤트가 일어날 때까지 기다릴 수 있다. (wait_event())
  • 프로세스들은 이벤트가 일어나면 신호를 보낸다. (signal_event())

잠금

공유 일관성을 보장하기 위해 공유 데이터를 잠글 수 있는 시스템 콜도 있다.

• 잠금이 해제될 때까지 어느 프로세스도 데이터에 접근할 수 없음.

싱글 태스킹 시스템과 멀티 태스킹 시스템

싱글 태스킹

• 다른 스케치가 적재되면 기존 스케치를 대체한다.
  • 스케치 : USB 연결을 통해 컴파일된 프로그램.

다중 태스킹

명령 인터프리터는 다른 프로그램이 실행되는 동안 수행을 계속할 수 있다.

1. 새로운 프로세스를 실행하기 위해 fork()
2. 선택된 프로그램이 exec() 를 통해 메모리 적재.
3. 프로그램이 수행
   • shell 은 프로세스가 종료하길 기다리거나 “백그라운드” 에서 프로세스 수행.
     • 프로세스가 백그라운드에서 수행될 때, 그 프로세스는 키보드로부터 직접 입력을 받을 수 없다. 셸이 그 자원을 사용하고 있기 때문이다.
     • 반면 사용자가 셸에게 다른 프로그램을 수행하도록 요청하거나, 프로세스의 진행 상황을 감시하거나, 프로그램 우선 순위를 변경하는 등의 요청 자유 있음.
4. 프로세스가 끝나면 종료를 위해 exit()
5. 호출한 프로세스에게 상태 코드0 을 돌려줌(오류 상황이라면 0이 아닌 오류 코드).

파일 시스템 시스템 콜 종류

• 생성, 삭제
  • 파일 이름이나 파일 속성의 일부를 요구함.
• 열기, 읽기, 쓰기
• 위치 변경
  • 예) 되감기, 파일 끝으로 건너뛰기
• 파일 닫기
• 파일 속성 획득
  • 파일 이름
  • 유형
  • 보호 코드
  • 회계 정보
• 여러 속성의 값을 결정, 재설정.
• 파일 이동, 복사

→ 파일이나 디렉토리 상관없이 이 같은 연산 집합이 필요.

💡코드와 다른 시스템 콜을 이용해서 동일한 작업을 수행하는 API 를 제공하거나, 일부 시스템은 단순히 동일한 작업을 수행하는 프로그램을 제공하기도 함.
→ 프로그램이 다른 프로그램에 의해 호출 가능하다면 → 다른 프로그램 입장에선 이 시스템 프로그램이 API

장치 관리

운영체제에 의해 제어되는 다양한 자원들은 장치로 간주될 수 있음.

• 예1) 주 기억장치, 디스크 드라이브
• 예2) 추상적, 가상적 장치(파일)

장치 사용

• 자원을 사용하면, 이 자원이 주어지고 제어가 사용자 프로그램으로 복귀.
• 또는 자원이 사용가능할 때까지 기다릴 수도 있다.

장치 관리 시스템 콜

독점적인 장치 사용을 보장받기 위한다는 전제를 깐다.

• 장치 요청과 장치 사용 후, 장치 방출
  • 파일 열기 닫기와 비슷함.
• 다른 운영체제들은 장치에 대해 통제되지 않은 접근을 허용함. (관리되지 않은 엑세스 허용)
  • 위험) 경쟁, 교착상태 유발 가능.

정보 유지 관리

시스템 콜 중 많은 것들은 사용자 프로그램과 운영체제 간의 정보 전달을 위해 존재 함.

• 현재 시간
• 날짜
• 운영체제 버전 번호
• 디스크 공간

메모리 덤프(dump)

• 디버깅에 좋은 시스템 콜.
  • 프로그램 스냅샷을 찍어 덤프하여 당시의 실행 상태를 복원하면 디버깅 재현 가능.

시간 프로파일

프로그램이 특정 위치에서 수행한 시간. (특정 위치에서 수행을 얼마나 했는지 나타내는 시간.)

• 추적 설비(tracing facility) 나 정규 타이머 인터럽트 필요.
• 타이머 인터럽트가 일어날 때마다 PC 에 값 기록.
• 타이머 인터럽트가 충분히 일어나면, 프로그램의 여러 부분에서 얼만큼 시간을 소비했는지 통계적 그림을 볼 수 있음.

프로세스 정보 획득

OS는 현재 운영되고 있는 모든 프로세스에 대한 정보를 가지고 있기에 그 정보에 접근하기 위한 시스템 콜이 있음.

• 프로세스 접근
• 프로세스 획득, 설정.

통신

통신 모델에는 일반적으로 메시지 전달과 공유 메모리, 두 가지의 모델이 있음.

메시지 전달 모델

통신하는 두 프로세스가 정보를 교환하기 위해 직접 메시지를 주고 받는다.

• 통신이 이뤄지기 전에 연결이 반드시 열려야 함.
• 통신자가 같은 컴퓨터에 있는 프로세스든, 다른 컴퓨터에 있든 그 프로세스의 이름을 반드시 알고 있어야 한다.
  • 호스트 이름 → 컴퓨터 식별자
  • 프로세스 이름 → 프로세스 식별자
  • 이 이름이 운영체제에 의해 동등한 식별자로 변환되고 프로세스를 가리키는 데 사용한다.
• 연결이 필요하기 때문에, 커넥션을 열거나 닫는 시스템 콜도 있다.
  • 연결을 받을 프로세스는 데몬으로 작동한다.
  • 대기 상태에 있다가 연결이 이뤄질 때 깨어남.
• 클라이언트와 서버간의 통신을 위한 시스템콜이 존재한다.
• 소량의 데이터를 교환할 때 유용하다.
  • 피해야 할 충돌이 없음.

공유 메모리 모델

정상적으로 운영되는 운영체제는 프로세스들이 서로의 메모리에 접근하는 것을 막는다. 그래서 다른 프로세스가 소유한 메모리에 접근 제한을 풀 수 있도록 동의 해야 한다.

• 공유 영역에서 데이터를 읽고 쓴다.
• 데이터 형식은 프로세스들에 의해 결정된다.
• 동일한 위치에 동시에 쓰지 않도록 보장할 책임이 있다.
• 대량의 데이터에 관해 최대 속도와 편리한 통신을 이용할 수 있다.
  • 하지만 보호와 동기화 부분에서 문제점을 가진다.

보호

컴퓨터 시스템이 제공하는 자원에 대한 접근을 제어한다.

• 네트워킹과 인터넷의 출현으로 서버에서 휴대용 컴퓨터까지 모든 컴퓨터 시스템에서 보호를 고려해야 한다.
• 파일과 디스크에 대한 자원의 허가를 할 수 있는 시스템 콜이 있음.
• 특정 사용자가 지정된 자원에 접근이 허가되었는지 불허되었는지 알 수 있음.