Operating System Services
운영체제는 사용자에게 도움을 주기 위해 여러 서비스들을 제공한다.
1. User Interface: 사용자 <-> 시스템 연결 창구
- CLI(Command Line Interface)- 명령어 기반
- GUI(Graphics User Interface)- 그래픽 기반
- Batch- 프로그램과 데이터만 주면 오랜시간 사용자와의 interaction 없이 알아서 작업 수행
2. Program execution: 프로그램 실행
- 프로그램을 메모리에 load
- CPU에 실행 요청
- 실행 종료 (정상/에러)
-> 이런 작업들을 수행
3. I/O operations
- 프로그램이 입/출력 장치를 사용할 때 OS가 중간에서 처리
4. File-system manipulation: 파일 관리 기능
- 파일 생성/삭제, 읽기/쓰기, 검색, 권한 관리
5. Communications
- 한 컴퓨터 내 두 개의 서로 다른 프로세스 간 OR 두 컴퓨터 간의 통신
- 방식1: Shared memory 방식
-> A라는 프로세스와 B라는 프로세스가 데이터를 주고 받는 상황에서, A, B 같이 접근할 수 있는 영역을 메모리에 저장해놓음. - 방식2: Message passing 방식
-> A에서 B로 데이터를 보낼 때, packet 단위로 데이터를 보냄
6. Error detection
- CPU, 메모리, I/O 장치, 사용자 프로그램 등등에서 error가 발생할 수 있는데, 이때 error가 발생했음을 interrrupt로 OS에게 알리고, OS는 interrupt를 처리함. + debugging 기능 제공
운영체제는 또한 시스템의 효율성을 위해 아래와 같은 여러 서비스들을 제공한다.
1. Resource allocation
- CPU, 메모리, I/O장치 등에 효율적이고 공평하게 자원을 분배하고, 다시 수거하는 서비스
2. Accounting
- 어느 사용자가 어느 자원을 얼만큼 사용하는지 추적하고 관리.
- 각 자원 별로 이용률을 모니터링하다가, 시스템의 성능이 떨어져 이를 업그레이드 해야할때, 가장 적은 돈으로 뭘 업그레이드 하면 가장 효과적이고 효율적일까 라는 상황에서 이런 accounting 기록이 이용됨.
3. Protection and Security
- Protection(보호): 시스템 자원 접근 제어
- Security(보안): 인증 및 외부 공격 방어
User Operating System Interface
1) CLI (Command Line Interface)
- 사용자가 명령어 직접 입력
- shell을 통해 실행
- 구현 방식
1) 명령어들을 kernel에서 미리 다 만들어놓고 그 안에 built-in으로 넣어둠 -> 속도fast, 변경hard, shell modification 필요
2) system program 형태로 각각의 명령어 파일들을 만들어 특정 디렉토리 안에 다 넣어둠 -> 속도slow, 변경easy, shell modification 불필요
2) GUI (Graphical User Interface)
- 아이콘, 마우스 기반 인터페이스
- 사용자 친화적
- 요즘 대부분의 시스템은 CLI + GUI 함께 제공
System Calls
운영체제에서 제공하는 서비스에 접근할 수 있게하는 interface 역할을 하는 것이 system call이다.
✔ 특징
- C/C++ 같은 고급 언어로 작성됨
- system calls을 직접적으로 호출하는 경우보다는 시스템에서 제공하는 API를 통해 system calls을 사용함
- 대표 API
- Win32 API
- POSIX API
- Java API
왜 system call을 직접 사용하지 않고 API를 이용?
-> system call의 종류가 너무 많아 복잡함. 이때 API를 제공하면, 그 하부에 있는 system call들이 자동으로 실행됨. 즉 system call을 직접 사용하는 것보다 편리하고 효율적임.
System Calls 예시
위 그림은 source file의 내용을 destination file로 copy할때의 system calls의 예시다. 앞단에 나와있는 것들이 system calls이라고 이해하면 되고, 직관적인 이름이 부여된 것을 알 수 있다.
이 그림은 Win32 API 안에 있는 ReadFile() 함수가 어떻게 구성이 되어있는지를 나타낸 그림이다.
<파라미터들>
- HANDLE file: 읽어올 파일
- LPVOID buffer: 읽어온 값을 저장하는 버퍼
- DWORD bytesToRead: 읽어와야할 데이터의 bytes수
- LPDWORD bytesRead: 지금까지 얼마나 읽어왔나
- LPOVERLAPPED ovl: I/O 작업이 overlapped 돼서 이루어지고 있는가
-> 즉 위 예시를 통해, system call을 직접적으로 호출하는 것보다 API를 통해 system call을 사용하는 것이 훨씬 간편하고 효율적이라는 것을 알 수 있다.
System Call implementation
✔ 각 system call들에 고유한 번호를 할당하고, kernel level에 이 번호들을 인덱스로 사용하는 테이블이 존재한다. 즉 사용자가 특정 system call을 호출하면, 인터페이스는 이 테이블을 보고 커널 내의 해당 함수를 찾아 실행한다. 이때 system call table은 인덱스 값과 그 인덱스에 대응하는 실제 함수들의 메모리 주소가 저장되어 있다.
✔ API를 이용하는 경우 사용자는 system call에 대해 하나도 몰라도 된다. 단지 API 호출 규칙을 준수하기만 하면 된다.
✔ 즉 대부분의 세부 사항은 프로그래머에게 숨겨져 있으며, 이는 런타임 지원 라이브러리가 관리한다.
API, System call, OS 사이의 관계
위 그림을 보면, user application이 C언어로 작성된 어떤 프로그램에 해당한다. 이때 printf()는 C 라이브러리에서 제공하는 함수이며, printf()라는 함수에서 write()라는 system call을 호출한다. 이후 그 write()라는 system call이 실행되는 과정이 바로 인덱스 값과 그 인덱스에 대응하는 실제 함수들의 메모리 주소를 보고 실행하는 과정이다. 이후 return값이 system call interface로 올라가고, system call interface는 이 값을 다시 user application으로 돌려주는 흐름인 것을 알 수 있다.
System Call Parameter Passing
위에서 봤듯이 system call 호출 시 OS에게 여러 파라미터 값들을 전달해야 하고, 이러한 파라미터들을 전달하는 방법에는 크게 세가지 방법이 있다.
1. Register 이용 (가장 간단)
CPU 주변의 레지스터들을 이용해 파라미터 값들을 전달할 수 있으며, 이때 여유분으로 남아있는 레지스터의 개수보다 파라미터의 개수가 더 많을 경우 문제가 발생할 수 있다.
2. Memory 이용
파라미터들을 메모리의 특정 블록이나 테이블에 한꺼번에 저장하고, 그 블록이 시작되는 메모리 주소만 레지스터에 담아 OS에 넘겨준다. 주로 linux 계열에서 많이 사용된다.
그림의 예시를 통해 memory를 이용하는 방식의 흐름을 알아보자.
위 그림의 왼쪽 파란색 박스를 보면, 프로그램은 system call(13번)에 필요한 파라미터들을 메모리의 특정 구역(X)에 미리 적어둔다.
이후 파라미터 데이터 그 자체가 아닌 그 데이터가 시작되는 메모리 주소값(address X)을 CPU의 레지스터(register)에 담는다.
프로그램이 system call 13번을 호출하면 제어권이 OS로 넘어가고, OS는 레지스터를 확인해 파라미터들이 메모리 address X번지부터 기록돼 있다는 것을 알게 된다.
이후 OS는 해당 주소를 참조해 메모리에서 필요한 매개변수들을 읽어오고, 읽어온 정보를 바탕으로 system call 13번의 실제 기능을 수행한다.
3. Stack 이용
프로그램이 파라미터를 메모리의 stack 영역에 집어넣고(Push), OS가 그 stack에서 값을 꺼내가는(Pop) 방식이다.
Types of System Calls
system call의 유형에는 아래와 같이 크게 5가지의 유형이 있다.
1. Process Control
- 프로그램을 실행하고 종료하며, 메모리를 할당하는 등 실행 중인 프로그램(=프로세스)을 관리
- end, abort
- load, execute
- create process, terminate process
- wait event, signal event
- allocate/free memory
2. File Management
- 파일을 만들거나 읽고 쓰는 등 저장 장치 내의 데이터를 관리
- create/delete file
- open/close
- read/write
- get/set file attributes
3. Device Management
- 물리적인 하드웨어 장치를 제어
- request/release device
- get/set device attributes
4. Information Maintenance
- 시스템의 시간, 날짜, 시스템 정보(CPU 버전, OS 정보 등)를 가져오거나 설정
- get/set system data
5. Communications
- 서로 다른 프로세스나 네트워크로 연결된 컴퓨터끼리 데이터를 주고받음
- create/delete connection
- send/receive message
System Programs
프로그램의 개발과 실행을 위해 편리한 환경을 제공해주는 것이 system program이다.
사용자 입장에서 보이는 OS 기능들이 System Program이다.
system program들의 밑단에는 system call들이 있으며, 이는 눈에 보이지 않는다.
system program은 아래와 같이 6개로 이루어져있다.
1. File management
파일과 디렉터리를 조작하는 기능을 제공한다.
2. Status information
날짜, 시간, 메모리 공간, 디버깅 정보 등 시스템 상태의 정보를 제공하며, 설정 정보(Configuration)를 저장하고 관리하기 위해 registry(set of registers)라는 system program을 사용한다.
3. File modification
텍스트 에디터를 통해 파일을 새로 생성하거나 수정한다. 추가로 search 기능도 제공한다.
4. Programming language support
컴파일러, 어셈블러, 인터프리터 등으로 프로그래밍 언어를 지원한다.
5. Program loading and execution
프로그램을 메모리에 load하는 과정을 관리한다.
- Absolute loaders: 디스크에 있는 프로그램을 메모리에 올렸을때, 메모리에 올라간 그 위치값이 절대 바뀌지 않음
- Relocatable loaders: 메모리에 올라간 프로그램의 위치를 옮길 수 있음
- Linkage editors: 여러 개의 코드 파일을 하나로 묶어 실행 가능한 형태로 만듦
- Overlay-loaders: 프로그램을 overlay로 분할하여 각 블록을 메모리에 로드함
6. Communications
프로세스와 프로세스 또는 컴퓨터와 컴퓨터 사이에 정보를 주고받을 일이 있을 때 그 기능을 제공한다.
Operating System Design and Implementation
운영체제의 설계와 구현의 측면에서는 어떠한 개발방법이 중요한게 아니라, 운영체제의 목표에 따라 다양하게 설계 및 구현이 된다.
✔ 목표
-
User goals (사용자 목표)
- 사용하기 쉽고, 배우기 쉬워야함
- 빠름
- 신뢰성
-
System goals (시스템 목표)
- 설계/구현/유지보수 용이
- 효율성
✔ 핵심 개념: Policy vs Mechanism
-
Policy (정책)
- 무엇을 할 것인가
-
Mechanism
- 어떻게 할 것인가
policy와 mechanism을 섞지 않고 반드시 서로 분리하는 것이 중요하다. 그래야 추후에 policy가 바뀌더라도 유연성 확보가 가능하다.
예를 들어, 어떤 한 프로그램의 무한 루프를 방지하는 상황에서, policy는 "무한루프를 방지해야한다" 이고, mechanism은 "어떻게 무한루프를 방지할까" 이다. 이때 그 프로그램의 사용자가 학생들이라고 했을때, 단순한 사용 환경을 가정하여 “일정 횟수 이상 반복되면 종료한다”는 방식으로 구현하고, 이를 4비트 카운터(최대 15회)로 제한했다고 하자.
여기서
- Policy: 반복을 어디까지 허용할 것인가
- Mechanism: 카운터를 사용해 반복 횟수를 제한한다
이때의 문제는 “4비트 카운터”라는 선택이다.
이는 “최대 15회까지만 허용”이라는 정책까지 포함한, 즉 policy를 mechanism에 포함시킨 설계다.
이후 프로그램이 연구 개발용으로 변경되어 더 많은 반복이 필요해지면, 단순히 policy만 바꾸는 것이 아니라 mechanism까지 수정해야 한다.
따라서 mechanism(카운터 구조)은 유지하고 policy(최대 반복 횟수)는 변경 가능하게 분리하는 것이 올바른 설계이다.
Simple Structure
MS-DOS
- 메모리의 크기가 매우 작았음
- 모듈 간의 기능 분리가 없었음
- 구조 비효율적
Layered Approach
- 여러 계층으로 구성
- 상위 레이어는 하위 레이어에서 제공하는 기능을 사용할 수 있음.
-> 3번 레이어는 0번, 1번, 2번 레이어에서 제공하는 기능을 사용하여 만들수 있음. 그러나 3번 레이어는 4번, 5번 레이어가 제공하는 기능은 사용할 수 없음 - 모듈화 → 유지보수 용이
UNIX
UNIX는 크게 두 개의 파트로 구성되어 있다.
1. System programs
그림을 통해 보면, 커널의 윗부분에 해당하며, 사용자가 직접적으로 상호작용하는 부분이다.
2. The kernel
- Kernel 역할
- CPU scheduling
- Memory management
- File system
-> 단점: UNIX 구조는 너무 많은 기능이 커널 안에 들어가 커널이 커지는 문제가 발생하고, 여러 기능이 맞물려 있어서 커널 내의 어떤 기능을 수정하려고 하면 이것들이 서로 맞물려 수정이 굉장히 복잡하고 어렵다.
Microkernel System Structure
- 핵심 기능만 갖도록 커널을 경량화시킴
- 나머지는 user space로 내보냄
- 커널들을 모두 모듈화시켜 message passing방식으로 통신하게 함
✔ 장점
- 확장성
- 안정성
- 보안성
✔ 단점
- message passing → 오버헤드 발생 가능
Modules
- 객체지향 방식으로 만들어짐
- 각 모듈은 기능 중심으로 분리됨
- 필요 시 동적 로드
- Microkernel구조, layerd approach구조 모두 모듈화가 되어있지만 microkernel 구조가 더 유연성이 좋음
Virtual Machines
- 하드웨어 위에 여러 OS 실행
- 즉 한 컴퓨터 위에서 여러 개의 컴퓨터를 돌릴 수 있도록 만들어진 개념
(a) Nonvirtual machine
하드웨어 위에 하나의 커널(OS)이 올라가고, 그 위에서 여러 프로세스가 실행되며, 모든 프로세스가 하나의 OS 자원을 공유한다.
(b) Virtual machine (가상 머신)
하드웨어 바로 위에 Virtual-machine implementation이라는 층이 추가된다.
그 위로 여러 개의 독립된 VM(VM1, VM2, VM3)이 생성되며, 각 VM은자신만의 커널(OS)을 별도로 가질 수 있다.
즉 결과적으로 하나의 컴퓨터 안에서 리눅스, 윈도우 등을 동시에 독립적으로 돌릴 수 있게 된다.
✔ 특징
- Hardware → VM → OS 구조
- CPU scheduling으로 자원 분배
- Protection & Isolation: 각 VM은 완전히 독립된 환경을 가져 특정 VM에서 장애가 발생하거나 보안 문제가 생겨도 다른 VM이나 실제 물리 시스템에는 영향을 주지 않음
- Research & Development: 새로운 운영체제를 개발하거나 시스템을 테스트할 때 매우 유용
- Difficult to implement: 물리적인 하드웨어와 똑같은 복제본을 소프트웨어로 만들어내야 하므로 구현 난이도가 높음
VMware architecture
요즘은 VMware라는 가상화 플랫폼이 가장 많이 쓰인다.
The Java Virtual Machine (JVM)
JVM은 호환성이 좋아 JVM이 깔려있는 컴퓨터는 서로 다른 컴퓨터에도 동일한 프로그램을 실행시킬 수 있다.
Operating System Generation(설치)
설치의 첫단계로, 해당 컴퓨터 시스템의 하드웨어들에 대한 구성 정보들을 파악해야 한다.
✔ SYSGEN program
- 하드웨어 정보 수집
- OS 설정 구성
✔ Bootstrap program
- booting 과정을 실행
System Boot
부팅과정은 크게 두 단계로 나눌 수 있다.
1. bootstrap loader 프로그램이 어디있는지 파악
2. bootstrap program이 돌면서 실제 booting 작업 실행
✔ Boot 과정
- 전원 ON
- ROM의 Bootstrap program 실행
- Kernel 위치 탐색
- Kernel 메모리 로드
- OS 실행
✔ Bootstrap Program
- ROM에 저장된 코드
- Kernel을 찾아 실행
