해당 게시글은 kocw에서 제공하는 금오공과대학교 최태영 교수님의 무료 강의를 공부하고 정리하기 위해서 만들어졌습니다.
System call 파라미터 전달
- fscanf 함수를 호출한다고 했을 때,
- 파라미터와 함께 호출 된다.
- fscanf 내부에서 API인 read 함수를 파라미터와 함께 호출
- 이 때 파라미터는 fscanf로 넘겨받은 파라미터와 다름
- read API 함수 내에서는 system.call을 호출한다.
- system.call에 어떤 서비스(read)인지 전달, 이 값은 상수이다.
- system.call 내에서는 어떤 서비스(read) 였는지 EAX 레지스터에 저장하고 interrupt 128번을 호출 한다.
- 128에 해당되는 인터럽트 핸들러 루틴에서는 서비스 주소를 가지고 있는 테이블을 참조하고 있다.
- EAX 레지스터에 저장된 상수 값을 가지고 이 테이블에서 서비스 주소를 찾는다.
- 찾은 서비스 주소를 가지고 호출하게 되는데, 이 때 파라미터를 전달하는 방법이 있다.
- cpu가 사용하는 레지스터에 파라미터를 집어넣는 방식
- 각 전달받은 파라미터들을 하나의 레지스터에 각각 저장한다.
- 호출된 서비스에서는 저장된 값들을 레지스터에서 꺼내서 쓰기만 하면 된다.
- 이 방식의 장점은 레지스터를 활용했기 때문에 속도가 빠르고, 구현하기 쉽다는 점이다.
- 단점은 하드웨어에 따라 레지스터의 크기가 작은 경우 이 방법을 쓸 수 가 없다.
- 인텔 컴퓨터 중 8개의 레지스터 밖에 제공되지 않는 컴퓨터가 있음
- 특정한 메모리를 할당받는 방식
- 메모리에 전달받은 파라미터를 저장한다.
- EBX 레지스터에 이 메모리 주소를 로딩한다.
- system.call에서 서비스를 호출할 때, EBX 레지스터에 저장된 메모리 위치를 활용하여 파리미터를 가져온다.
- Load ECX, EBX[0]
- Load EDX, EBX[1]
- Load xxx, EBX[2]
- 이 방식의 장점은 메모리에 여유만 있다면, 얼마든지 많은 파리미터를 전달해 줄 수 있다. 그렇기 때문에 범용성이 높아진다.
- 단점은 첫 번째 방법에 비해 속도가 떨어지고, 메모리 확보를 위한 시간이 필요하다. 또한 한 메모리에 있는 내용을 다른 메모리에 옮겨주어야 한다.
- 해당 방식은 리눅스와 솔라리스에서 사용되고 있다.
- 보통 함수를 호출할 때, call을 호출하는 방식
- 일반적인 경우 각 프로세스들은 stack을 가진다.
- stack에는 return address, 파라미터, local variable을 담아둔다.
- 이런 것처럼 마찬가지로 system call에도 stack을 두고 필요한 파라미터를 담아둔다.
- 실제로 system call에서 서비스를 호출 할 때, stack의 내용을 꺼내서 쓴다.
- 리눅스와 솔라리스에서는 2, 3번 방법을 다 쓰며 파라미터가 적으면 두 번째 방법을, 많으면 세 번째 방법을 쓴다.
- 해당 방식은 stack에 넣은 순서를 잘 고려해서 써야 한다.
System call 타입
- 사실 kernel이 해주는 일과 System.call이 해주는 일은 동일하다.
- 차이는 system.call은 사용자가 요구하는 일이라는 것이고,
- kernel은 사용자가 요구하지 않아도 처리되는 일이라는 것이다.
- protection, security 같은 것들
- System.call은 다음과 같은 역할들을 한다.
- process 제어
- 프로세스 생성, 제거
- 프로세스간 통신
- 프로세스 실행 중단
- 등등
- File 관리
- 파일 생성, 제거
- 파일 열기, 닫기
- 읽기, 쓰기, 위치 변경
- 등등
- Device 관리
- 디바이스를 접근하여 제어하는 것들
- 디바이스 읽기, 쓰기, 위치 변경
- 등등
- 파일과 매우 흡사한데, 이는 리눅스 상에서 디바이스를 파일처럼 다루게 하기 때문이다.
- open, close, read, write 등
- Information maintenance(시스템 정보)
- Communications(통신)
- Protection
- POSIX Standard를 만들 때, 되도록 적은 API와 System.call을 제공하자는 철학을 바탕으로 만들어서 필요한 system.call만 현재는 제공되고 있다.
- 윈도우에서도 이러한 system.call과 1대1로 매핑된 것들이 있다.
System programs
- OS와 하드웨어를 활용하기 위해서 사용자에게 제공되는 프로그램이다.
- 대표적인 시스템으로,
- 시스템 프로그램을 통해서 사용자는 원하는 일을 수행한다.
- 파일 관리, 시스템 정보 확인, 컴파일러, shell 실행 등
- Background Program
- 시스템 프로그램 중에서 사용자 입력이나 요청을 받지 않고 주어진 일만 하는 프로그램을 Background Program이라고 한다.
- 네트워크 데이터 처리
- 디스크 상태 체크
- 프린트 기능
- 이런 것들이 하나의 프로세스로서 동작하게 된다.
- Application Program
- 이외 프로그램들은 일반적으로 Application Program이라고 한다.
- User Interface(UI)에 포함되는 시스템 프로그램
- shell, gui 프로그램 이 두가지는 기본적으로 포함된다.
- 나머지 시스템 프로그램은 이 UI를 통해 기본적으로 실행된다.
- 시스템 프로그램은 User Interface를 포함한다.
- bios는 cmos나 ROM에 들어있다.
- bios는 부팅 때 짧게 쓰이며,
- 현재 컴퓨터에 붙어 있는 디바이스들을 체크하고
- bootstrap 기능을 실행한다.
- bios는 하드웨어의 작은 부분으로 존재하며, os에 포함되지 않는다.
- 따라서 시스템 프로그램이 아니다.
운영체제 디자인
- 대부분은 풀 수 없는 문제들이다.
- 목적을 정확히 정해야 한다.
- 어떤 하드웨어에서 쓰일지 명확해야 한다.
- 시스템에서 하드웨어를 효율적으로 사용할 수 있도록 해야 한다.
- 이러한 것을 정리해보면 아래 두가지로 나눌 수 있다.
- Policy: 정책, 무엇을 할 것인가?
- Mechanism: 정책을 어떻게 동작하게 할 것인가?
- search 기능에 이 두가지 개념을 도입해보면
- Policy: search
- Mechanism: linear search, search tree, hash
- 위와 같은 방식으로 표현할 수 있다.
운영체제 구현
- 어떤 프로그래밍 언어를 쓸지 결정
- 초기에는 어셈블리로 구현
- 현재는 c, c++
- Profile을 통해 사용빈도가 높은 부분만 어셈블리로 구현