2.1 운영체제 서비스
•
사용자 인터페이스
•
프로그램 수행: 프로그램을 메모리에 적재해 실행 할 수 있어야한다. 정상적이든 아니든 실행을 잘 끝내자.
•
입출력 연산: 파일 혹은 입출력 장치로 입출력을 할 수 있다. 운영체제가 입출력 수행의 수단을 제공
•
파일 시스템 조작: 파일 생성,삭제,검색,권한 관리 등등
•
통신: 프로세스 간의 정보 공유. 공유 메모리 또는 메시지 전달 등의 기법
•
오류 탐지: CPU, 메모리 하드웨어 등등 오류에 대한 적당한 조치
•
자원 할당: 각 프로세스에 자원을 할당해줘야함. CPU를 최대한 효율적으로 이용하기 위해 CPU 속도, 반드시 실행해야할 프로세스들, 처리 코어 개수와 다른 요인들을 함께 고려할 수 있도록
•
기록 작성: 사용 기록
•
보호와 보안: 컴퓨터 시스템 또는 네트워크로 연결된 컴퓨터 시스템에 저장된 정보의 보호.
사용자와 운영체제 인터페이스
명령 인터프리터
사용자가 지정한 명령을 가져와서 그것을 수행
UNIX 시스템의 셸은 두 가지 방식으로 구현됨
•
명령 인터프리터 자체가 실행할 코드를 가지고 있는 경우
◦
명령을 만나면 적당한 코드로 분기하고 직접 실행함.
•
시스템 프로그램에 의해 대부분의 명령을 구현하는 경우
◦
명령 등이 메모리에 적재되어 있다.
◦
명령 인터프리터가 아주 작아질 수 있으며, 새로운 명령을 추가하기 위해 변경될 필요가 없다.
시스템 콜
응용 프로그램 인터페이스
API는 각 함수에 전달되어야 할 매개변수들과 프로그래머가 기대할 수 있는 반환 값을 포함하여 응용 프로그래머가 사용 가능한 함수의 집합을 명시
운영체제가 제공하는 라이브러리를 통해 API를 활용할 수 있다.
실제 시스템 콜을 부르는 것보다 API에 따라 프로그래밍하기를 선호하냐?
→ API에 따라 프로그램을 설계하면 같은 API를 지원하는 어느 시스템에서건 컴파일되고 실행될 것을 기대
→실제 시스템 콜을 종종 더 자세한 명세가 필요하고 프로그램 상 작업하기가 API보다 어려움
RTE
RunTime Environment
RTE는 시스템 콜에 대한 연결고리 역할을 하는 시스템 콜 인터페이스를 제공함.
API함수의 호출을 가로체어 필요한 운영체제 시스템 콜을 호출
각 시스템 콜에는 번호가 할당되고 시스템 콜 인터페이스는 이 번호에 따라 색인되는 테이블을 유지.
이렇게 하면 시스템 콜이 어떻게 구현되고 무슨 작업을 하는지 아무것도 알 필요가 없다. 호출자는 단지 API를 준수하고 시스템 콜의 결과로서 운영체제가 무엇을 할 것인지만 이해하면 됨.
따라서 운영체제 인터페이스가 은닉화되고, RTE에 으해 관리됨.
운영체제에서 매개변수를 전달하는 방법
•
매개변수를 레지스터 내에 전달하기
◦
어떤 경우는 레지스터보다 많은 매개변수가 잇을 수도 있다.
•
메모리 내의 블록이나 테이블에 저장되고, 블록의 주소가 레지스터에 담겨서 전달 됨.
◦
Linux는 이러한 접근법을 조합해서 사용
◦
5개 이하는 레지스터로, 초과하면 블록 방법
•
매개변수가 스택에 넣어질 수 있고, 운영체제에 의해 꺼내진다.
◦
이 접근법은 매개변수의 개수나 길이를 제한하지 않는다.
시스템 콜의 유형
•
프로세스 제어
◦
fork()
◦
exit()
◦
wait()
•
파일 조작
◦
open()
◦
read()
•
장치 조작
◦
ioctl()
◦
read()
◦
write()
•
정보 유지 보수
◦
getpid()
◦
alarm()
◦
sleep()
•
통신
◦
pipe()
◦
shm_open()
◦
nmap()
•
보호
◦
chmod()
◦
umask()
◦
chown();
링커와 로더
시스템 대부분에서 프로그램이 적재될 때 라이브러리를 동적으로 링크할 수 있게 한다.
실행파일에서 사용되지 않을 수 있는 라이브러리를 링크하지 않고 로드하지 않아도 된다.
라이브러리는 조건부로 링크되며, 프로그램 실행 시간에 필요한 경우 적재된다.
대신 링커는 프로그램이 적재될 때 동적으로 링크되고 적재될 수 있도록 재배치 정보를 삽입
오브젝트 및 실행 파일을 일반적으로 표준화된 형식을 가진다.
이 표준 형식을 ELF라고 함. 재배치 가능 파일과 실행 파일 각각을 위한 별도의 ELF형식이 사용된다.
실행 가능 파일의 ELF파일 정보 중 하나는 프로그램 시작점이며, 실행할 첫 번째 명령어의 주소가 저장된다.
응용 프로그램이 운영체제마다 다른 이유
응용 프로그램이 여러 운영체제에서 실행 될 수 있게 하는 법
•
인터프리터 언어로 작성하자. 인터프리터는 소스 프로그램의 각 랑린을 읽고 상응하는 기계어 명령을 실행하고, 해당 운영체제의 시스템 콜을 호출
•
실행 중인 응용 프로그램을 포함하고 있는 가상 머신을 가진 언어로 작성. JAVA
•
컴파일러가 기기 및 운영체제 고유의 이진 파일을 생성하는 표준 언어 또는 API를 사용. 다양한 UNIX 운영체제 변종 간의 소스코드 호환성을 유지하기 위한 POSIX API와 표준 집합
하지만 이럼에도 불구하고 어려운 이유
•
각 운영체제에는 헤더,명려어 및 변수의 배치를 강제하는 응용 프로그램 이진 형식이 있다. 명시된 구조 형태로 실행 파일 내의 특정 위치에 있어야 운영체제가 응용 프로그램을 적재하여 올바르게 실행 가능
◦
즉, 운영체제마다 헤더와 명령어 등에 대한 규약이 있는데, 같은 이진 파일이라 하더라도 이진 파일을 읽어들이는 규칙이 다르기에, 응용 프로그램이 잘 실행이 안된다.
•
CPU는 다양한 명령어 집합을 가지며, 해당 명령어가 포함된 응용 프로그램만 올바르게 실행 가능
•
운영체제는 응용 프로그램이 파일 생성과 네트워크 연결 등의 활동을 요청하는 시스템 콜을 제공. 이 시스템 콜이 운영체제마다, 전부 다르다. 피연산자 순서, 시스템 콜 번호, 의미, 반환 결과 등등
운영체제 구조
모놀리식 구조
커널의 모든 기능을 단일 주소 공간에서 실행되는 단일 정적 이진 파일에 넣는다!
구현 및 확장이 어렵다.
성능 면에서는 뚜렷한 이점. 시스템 콜 인터페이스에서는 오버헤드가 거의 없고, 커널 안에서의 통신 속도가 빠르다.
계층적 접근
최하층은 하드웨어이고 최상층은 사용자 인터페이스
시스템을 계층으로 나누면 시스템의 설계나 구현이 간단해진다.
각 층은 다른 층의 구현에 전혀 신경쓰지 않고 구현할 수 있다.
각 층은 자신보다 하위 수준의 층에 의해 제공된 연산들만 사용해 구현.
이 방식은 컴퓨터 네트워크 및 웹 응용 프로그램에서 성공적으로 사용 됨. 하지만 이 방식을 사용하는 운영체제는 비교적 적은데
•
각 계층의 기능을 적절히 정의해야하는 문제
•
시스템의 전반적인 성능은 사용자 프로그램이 여러 계층을 통과해야하므로 오버헤드가 발생함.
마이크로커널
마이크로커널 접근 방식을 사용하여 커널을 모듈화한 Mach
모든 중요치 않은 구성 요소를 커널로부터 제거하고, 별도의 주소 공간에 존재하는 사용자 프로그램으로 구현하여 운영체제를 구성하는 방법→ 더 작은 커널을 만들 수 있다.
클라이언트 프로그램과 사용자 공간에서 수행되는 다양한 서비스 간에 통신을 제공해야한다.
클라이언트 프로그램이 파일에 접근하기를 원하면 파일 서비스를 사용해야한다.
장점은 운영체제의 확자이 쉽다. 새로운 서비스는 사용자 공간에 추가되며 커널을 변경할 필요가 없다.
만들어지는 운영체제는 하드웨어간 이식이 쉽다. 서비스가 사용자 프로세스로 실행되기에 더욱 높은 보안성과 신뢰성을 제공한다.
단점은 가중된 시스템 기능 오버헤드 때문에 성능이 나빠진다. 두 개의 사용자 수준 서비스가 통신해야하면, 별도의 주소 공간에 서비스가 존재하기 때문에 메시지가 복사되어야한다.
모듈
커널에 핵심 요소들이 있고 부가 서비스들을 modules를 통해 추가할 수 있다. 핵심 기능이 있는 커널이 돌아가는 와중에 다른 서비스들을 동적으로 추가하고 실행할 수 있다.
하지만 프로세스 간의 메시지 전달을 호출할 필요가 없기 때문에 마이크로 커널에 비해 더 효율적이다.
