[운영체제] 2. OS 서비스

 본 내용들은 전공수업으로 배운 내용들을 스스로 리마인드하기 위한 목적으로 작성되었으며, 누군가에게 지식을 전달하기 위한 목적으로 작성한 것이 아닙니다. 대부분의 내용은 제가 수강했던 전공수업 및 Operating System Concepts, 10th Edition에 근거하고 있습니다. 

 

 

1. OS 서비스

 

- OS는 프로그램 실행을 위한 환경 및 프로그램과 유저에게 서비스들을 제공한다 (아래의 6 + 3 서비스가 대표적)

 

유저에게 유용한 기능을 제공(6)

- User interface, Progream execution, I/O operations, File-system manipulation, Communications(Internal & External), Error Detection

 

Resource sharing을 통해 시스템 자체의 효율적인 동작을 보장(3)

- Resource allocation, Logging, Protection and security

 

 

2. 유저와 OS 인터페이스

 

CLI(Command Line Interpreter or Interface)

- 커널 내부에 구현 되어있거나 때로는 시스템 프로그램이기도 함

- 명령어는 셸 내부의 빌트인 명령어일 때도 있고, 프로그램의 이름일 때도 있음

 

GUI(Graphic User Interface): 유저 친화적

 

- 현대의 많은 시스템들이 CLI와 GUI를 둘다 보유, 터치스크린이나 음성 명령 같은 현대적인 인터페이스들도 있음

 

3. 시스템 콜

 

- 시스템 콜은 OS 서비스를 사용하기 위한 프로그래밍 인터페이스라고 볼 수 있음, 보통 직접 시스템 콜을 호출하기 보다는 high-level의 API를 통해 액세스 함(Win32 API, POSIX API, JAVA API 등)

- 흔히 떠올릴 수 있는, 키보드로 입력을 받고 파일을 열고 읽는 등의 시스템 작업들은 시스템 콜을 거친다

 

시스템 콜 구현

- 시스템 콜은 고유한 번호가 매핑되어 있으며 시스템 콜 인터페이스는 매핑된 그 테이블을 들고 있음

- 시스템 콜 인터페이스는 OS 커널에서 의도된 시스템 콜을 실행하고 그 시스템 콜의 상태와 필요한 결과 값들을 반환함

- 이런 구조이기 때문에, 시스템 콜 API를 호출하는 측에서는 시스템 콜이 실제로 어떻게 구현되어 있는지 알 필요가 없다. 

- 물론 이 과정 내에서도, 모드 스위칭은 일어나고 있음

 

시스템 콜 파라미터 패싱

- OS나 콜의 종류에 따라 정확한 타입의 많은 양의 정보를 파라미터로 넘겨야 함

- 세 가지 일반적인 방법이 있음

  - 레지스터를 통해 파라미터 패싱: 레지스터는 희소한 자원이며, 몇몇 경우에는 파라미터로 전달되어야 할 양이 레지스터 용량보다 클 수 있음

  - 파라미터는 메모리의 블록에 저장해두고, 레지스터를 통해 블록의 주소를 패싱: 리눅스와 솔라리스 등에서 사용

  - 프로그램이 메모리 스택에 파라미터를 push 하고, OS에서 pop 하여 사용

  : 아래의 두 가지 방법은 파라미터의 수나 길이에 제한받지 않고 넘길 수 있으며, 주로 이용되는 방식이다

 

시스템 콜의 타입

- 6개 정도로 분류할 수 있다

- Process Control: 프로세스 생성 및 종료, 시간 기다리기, 이벤트 기다리기, 이벤트 발생시키기, 메모리 할당 및 해제, 에러 발생시 메모리 덤프 뜨기, 디버거 한 스텝씩 동작시키기, 프로세스간 공유 데이터에 대한 lock 등

- File Mangement: 파일 생성 및 삭제, 파일 열기/닫기, 파일 쓰기/읽기/수정, 파일 속성 확인 및 설정 등

- Device Management: request/release device, device 쓰기/읽기/수정, device 속성 확인 및 설정, logically attach/detach  device 등

- Information maintenance: 시간 및 날짜 확인/설정, 시스템 데이터 확인/설정, 프로세스/파일/device 속성 확인 및 설정 등

- Communications: 통신연결 생성/삭제, 메세지 패싱 모델이라면 호스트나 프로세스에게 메시지 주고 받기, 공유 메모리 모델이라면 데이터 생성 및 획득을 위해 메모리 구역 접근하기, 상태 정보 전달, attach/detach remote device 등

- Protection: 리소스에 대한 컨트롤 액세스, 권한 얻기/설정, 유저 접근 허용 및 불허

 

 

4. 시스템 프로그램

- 시스템 프로그램들은 프로그램 개발 및 실행을 위한 편리한 환경을 제공한다.

- 시스템 콜이 커널 기능을 직접 호출하는 것이라면, 시스템 프로그램은 운영체제가 제공하는 사용자 프로그램이라고 볼 수 있음

- 일부는 단순히 시스템 콜에 대한 사용자 인터페이스지만, 일부는 꽤 복잡하다

- File management, Status information, File modification, Programming-language support, Program loading and execution, Communications, Background Services, Application programs

 

5. 링커와 로더

- 소스 코드는 물리적인 메모리 위치에 로드되기 위해서 오브젝트 파일로 컴파일 됨(relocatable object file)

- 링커는 이 오브젝트 파일들을 하나의 단일 이진 실행파일로 병합하며, 모든 사용하는 라이브러리도 함께 단일 실행파일로 구성됨(static link)

- 이렇게 생성된 이진 코드가 실행되기 위해서는 로더에 의해 메모리로 옮겨져야 함

- 현대의 범용 시스템들은 라이브러리들을 실행파일에 링크하지 않음(Windows의 DLLs와 같은 dynamically linked libraries 사용)

- 오브젝트 파일 및 실행 파일은 표준 포맷이 있고, OS는 그것들을 어떻게 로드하고 시작할지 알 수 있다

 

6. 기타

- 각 OS의 실행 파일들이 교차 실행되지 않는 것은 각 OS가 고유한 시스템 콜을 제공하기 때문이다

- 다양한 OS에서 실행되는 프로그램들은 인터프리터 언어로 다중 OS 실행을 염두에 두고 작성하거나, VM을 이용해 프로그램을 동작시키는 언어로 작성하거나, C 처럼 스탠다드한 언어로 크로스 컴파일 해야함

- Policy(무엇이 수행되어야 하는가)와 Mechanism(어떻게 수행할 것인가)를 분리하는 것은 OS 디자인에 있어서 중요한 원리이다

 

- 몇 가지 OS 구조

  - 모놀리식 구조: 단순하고 개발이 쉽지만 유지보수가 힘들다, UNIX 등

  - Layered Approach: 하드웨어단인 layer 0부터 user interface에 속하는 layer N까지 계층을 나누어 개발, 네트워크에서는 성공한 방식이지만 OS에선 정의와 오버헤드 문제가 있음

  - Microkernels: 커널의 대부분을 user space로 넘김, Mach가 대표적. 확장하기 쉽고, 새로운 아키텍처에 OS를 포팅하기 쉽고, More reliable, More secure하지만 user space와 커널 사이의 통신을 위한 메시지 패싱이 잦아 퍼포먼스 오버헤드 문제가 있음

  - Modules: 많은 현대의 OS가 loadable kernel modules(LKMs)을 구현함. 각각의 컴포넌트가 분리 가능하며 필요에 의해 커널에 로드될 수 있는 구조. Linux, Solaris 등

  - Hybrid Systems: 대부분의 현대 OS들은 성능, 보안, 사용성을 위해 복합적인 모델을 사용함. Linux나 Solaris 커널은 모놀리식하지만 일부 기능의 동적 로딩을 위한 모듈 방식도 함께 사용함, Windows도 대부분 모놀리식하지만, 일부는 OS personalities라는 별도의 하위 시스템을 user-mode process 형태로 지원하는 등 마이크로커널 방식 함께 사용.

 

- 시스템 부팅: 시스템에 전원이 켜지면, 고정된 메모리 위치에서부터 실행됨. OS는 하드웨어에서 이용할 수 있게 만들어지며, 그래서 하드웨어가 시작시킬 수 있음. 

 bootstrap loader, BIOS가 커널의 위치를 찾고, 커널이 메모리에 적재되고 시작된다. 커널은 하드웨어를 초기화 하고, 루트 파일 시스템이 마운트 된다.

 때때로 ROM 코드에 있는 고정된 위치가 담긴 boot block을 bootstrap loader가 disk로부터 로드하는 two-step 프로세스도 있음. 또 현대 시스템들은 BIOS를 UEFI로 대체하고 있다. GRUB와 같은 일반적인 bootstrap loader는 커널 매개변수를 설정하거나, 부팅 가능한 다른 커널을 사용하는 등 유연성을 가진다. 대부분의 bootstrap loader가 다양한 부팅 상태를 허용함(복구 모드, 단일 사용자 모드)

- OS 디버깅: Application의 실패는 프로세스의 메모리를 캡쳐한 core dump 생성, OS의 실패는 커널 메모리를 포함해 crash dump 생성.