* 시스템콜 : os에 서비스를 요청할 수 있는 메커니즘
- 커널모드로 전환 : 하드웨어 인터럽트, 트랩(소프트웨어 인터럽트)
- 응용프로그램에서 시스템콜 API 호출
- 시스템콜 API를 전형적으로 라이브러리에 저장
- 라이브러리에 있는 시스템콜 API를 호출하면서 OS에 서비스 요청
- 시스템콜 호출 시 OS 내 프로그램 수행을 위해 커널모드로 전환
* 중요한 설계 원리
- policy : 목적, 어떤 것을 할지
- machanism : 방법, 어떻게 할 건지
e.g.
- 어플리케이션이 서비스 요청을 함 (policy)-> 시스템콜(mechanism)
- cpu 리소스 제어를 유지함(policy) -> timer(mechanism)
*API
- 라이브러리에 내포
- Win32 API, POSIX(유닉스 계열에서 사용하는 함수 표준화)
* 시스템콜을 직접 호출하지 않고 API를 사용하는 이유
- 응용프로그래머는 라이브러리 함수를 호출하고 라이브러리 함수에는 시스템콜을 갖고 있음
- 응용프로그래머가 직접적으로 시스템콜을 호출하지 않고 라이브러리 함수를 통해 간접적으로 호출
- portability : 기계마다 시스템콜이 다르면 서로 다른 기기에서 별도의 시스템콜을 호출해야해서 프로그래머가 어려움을 겪음
공통적 API호출로 효과적인 프로그래밍
- Ease : 시스템콜에 대한 자세한 사항을 프로그래머가 알 필요가 없음
* 시스템콜 인터페이스
- 모든 시스템 콜을 모아둔 테이블
- 테이블 왼쪽에 넘버, 오른쪽에 시스템콜
-시스템콜이 워낙 많아서 넘버와 시스템콜로 이루어진 시스템콜 인터페이스를 사용
1. open() 함수 호출
2. open()에 해당하는 넘버를 받음
3. 받은 넘버로 시스템콜 인터페이스에서 look up
4. 함수의 주소가 시스템콜 인터페이스에서 호출됨
* 커널 내에 있는 프로그램이기 때문에 커널에 파라미터를 넘겨줘야 함
- 레지스터에 파라미터를 바로 넘겨주는 방식 : 파라미터가 많아지면 레지스터 개수의 한계로 문제 발생 가능
- 메모리 특정 위치에 '시스템콜을 통해서 커널에 넘겨줄 인자'를 저장하고 주소 값을 레지스터에 넘겨줌
: 레지스터 개수가 파라미터 개수의 영향을 받지 않음
- 리눅스에서는 두가지 방법을 혼용 : 인자의 개수가 6개 이하면 레지스터로 바로 전달, 6개 이상이면 주소값 전달
1. user에서 fork 함수 호출 -> 시스템콜은 라이브러리를 통해 간접적으로 호출
2. fork 라이브러리 함수를 찾음 (시스템콜 넘버 찾기) - 시스템콜 넘버가 2
3. 인터럽트 호출 (시스템콜은 트랩의 일종)
4. 운영체제는 인터럽트 벡터를 look up
5. 시스템콜인터페이스에서 시스템콜 넘버를 가진 시스템콜 함수 확인
6. 시스템콜 핸들러 호출
* 유저프로그램 : 시스템프로그램, 응용프로그램
* 시스템 프로그램
- 프로그램 개발, 실행에 편리한 환경 제공
- 시스템을 효과적으로 사용할 수 있도록 지원해주는 응용레벨 프로그램
- 하드웨어 접근, 파일관리, 프로그램 로딩과 실행, 커뮤니케이션 등
- 대부분의 유저들은 시스템콜이아니라 시스템프로그램에서 정의한 것을 봄
* 시스템콜의 종류
- 프로세스 관리
- 파일 관리
- 디바이스 관리
- 시간과 날짜 확인
- 프로세스간 커뮤니케이션 지원
'CS > 오퍼레이팅 시스템' 카테고리의 다른 글
9. 오퍼레이팅 시스템 구조 : 레이어, 마이크로커널, 모듈, 버츄어머신 (0) | 2020.04.08 |
---|---|
8. 오퍼레이팅 시스템 설계와 구현 (0) | 2020.04.08 |
6. 오퍼레이팅 시스템이 제공하는 서비스 (0) | 2020.04.08 |
5. 유저와 커널 (0) | 2020.04.08 |
4. 멀티프로그래밍 : 멀티프로세서, 멀티코어 (0) | 2020.04.07 |