System Services (= System Utilities)
시스템 프로그램은 프로그램 개발 및 실행에 편리한 환경 제공
대부분의 사용자는 실제 시스템 호출이 아닌 시스템 프로그램을 통해 운영체제를 보고있다.
- 파일 관리
파일 및 디렉토리 생성, 삭제, 복사, 이름변경, 인쇄, 덤프, 목록 및 일반적으로 파일 및 디렉토리 조작
- 상태 정보
시스템 정보 요청 - 날짜, 시간, 사용 가능한 메모리 양, 디스크 공간, 사용자 수 등
성능, 로깅 및 디버깅 정보 제공
일반적으로 이런 프로그램은 터미널이나 다른 출력장치로 출력을 서식화하고 인쇄함
일부 시스템에서는 레지스트리를 구현해서 구성 정보를 저장하고 검색하는데 사용함
- 파일 수정
파일 생성 및 수정을 위한 텍스트 편집기
파일 내용 검색 또는 텍스트 변환을 수행하는 특수 명령이다.
- 프로그래밍 언어 지원
컴파일러, 어셈블러, 디버거 및 인터프리터 제공
- 프로그램 로딩 및 실행
absolute loaders, relocatable loaders, linkage editors, overlay-loaders, 고급언어 및 기계어 디버깅 시스템
- 통신
프로세스, 사용자 및 컴퓨터 시스템 간 가상 연결을 생성하는 메커니즘 제공
- 백그라운드 서비스
부팅 시 자동으로 시작.
시스템 시작을 위한 것은 부팅 후 종료됨
시스템 부팅부터 종료까지 실행되는 것도 있음.
디스크 검사, 프로세스 스케줄링, 오류 로깅, 인쇄와 같은 기능 제공
사용자 컨텍스트에서 실행되고 커널 컨텍스트에선 실행되지 않음.
서비스, 서브시스템, 데몬으로 알려짐
- 애플리케이션 프로그램
시스템과 관련되지 않고, 사용자가 실행함.
일반적으로 운영체제의 일부로 간주되지 않고 명령줄, 마우스, 터치 입력으로 실행됨
Linkers and Loaders
오브젝트 파일: 소스 코드의 컴파일 결과로 임의의 물리 메모리 위치에 로드될 수 있도록 설계된, 재배치 가능한 파일
링커 : 오브젝트 파일들을 하나의 이진 실행 파일로 결합, 라이브러리도 가져온다.
로더: 보조기억장치에 저장된 프로그램을 실행하기 위해 메모리로 가져오는 역할.
재배치란 프로그램 부분에 최종 주소를 할당하고, 프로그램의 코드와 데이터를 그 주소에 맞게 조정하는 것
현대의 일반용 시스템은 라이브러리를 실행 파일에 링크하지 않고, DLL(동적 링크 라이브러리)를 필요할때마다 로드하며 해당 라이브러리의 동일 버전을 사용하는 모든 프로그램에서 공유된다.
오브젝트 파일과 실행 파일은 표준 형식을 갖고 있고, 운영체제는 이를 로드하고 실행할 수 있다.
애플리케이션이 운영체제 별로 다른 이유
각 운영체제는 고유한 시스템 콜, 파일 형식 등을 제공하기 때문.
애플리케이션이 멀티운영체제 시스템일 수도 있음.
- 파이썬과 같은 인터프리터로 작성된 경우
- JAVA와 같은 실행할 때 VM을 포함하는 언어일 경우
- C와 같은 표준 언어의 경우 각 운영체제에 대해 별도로 컴파일해서 실행 가능
ABI(Application Binary Interface): 특정 운영체제와 아키텍처, CPU 등에서 다른 이진 코드 구성 요소가 어떻게 인터페이스 할 수 있는지 정의함. (다른 구성 요소 간 어떻게 상호작용할 수 있는지 정의함)
Operating System Design and Implementation
사용자 목표 : 운영체제는 편리하게 사용할 수 있고, 배우기 쉽고, 신뢰성이 있고, 안전하고 빠르도록 유지해야 함
시스템 목표 : 운영체제는 쉽게 설계, 구현, 유지 관리할 수 있어야 하고 유연하고 신뢰성이 있고 오류가 없고 효율적이여야 함
운영체제의 설계 및 구현은 해결 가능한 문제는 아니지만 일부 접근 방법이 입증됐다.
다양한 운영체제의 내부 구조는 크게 다를 수 있다.
설계를 시작하기 전에 목표와 명세를 확실히 해야한다.
하드웨어 선택, 시스템 유형 등이 영향을 미친다.
정책(Policy)과 메커니즘(Mechanism)을 분리하는 것은 중요한 원칙이다.
Policy: 무엇을 할 것인가? (CPU 사용에 시간을 제한함)
Mechanism: 어떻게 하는가? (시간 측정을 위해 타이머를 사용함)
정책과 메커니즘의 분리는 정책 결정이 나중에 변경되어도 최대한의 유연성을 제공함.
운영체제를 지정하고 설계하는 것은 소프트웨어공학의 매우 창의적인 작업이다.
운영체제 구현에는 많은 변화가 있었음
- 초기에는 어셈블리어로 작성됨
- 그 이후에는 Algol, PL/1과 같은 시스템 프로그래밍 언어로 작성됨
- 지금은 C/C++로 작성됨
실제로는 언어를 혼합해서 사용함.
- 가장 낮은 레벨은 어셈블리어로 작성됨
- 메인은 C
- 시스템 프로그램은 C나 C++, PERL, Python과 같은 스크립트 언어, 셸 스크립트로 작성
더 높은 수준의 언어는 다른 하드웨어로 이식하기 더 쉬우나 느릴 수 있음
에뮬레이션을 사용해서 운영체제를 다른 하드웨어에서 실행할 수 있다.
일반적으로 운영체제는 매우 큰 프로그램이고, 구조화 하는 방법에는 다양한 방법이 있다.
- 간단한 구조 : MS-DOS
- 더 복잡한 구조 : UNIX
- 계층화된 추상화 구조나 마이크로커널 구조(Mach)가 있음
Monolithic Structure : Original UNIX
UNIX : 최초의 UNIX 운영체제는 하드웨어 기능에 제한을 받았다. UNIX OS는 두 가지로 구성된다.
- 시스템 프로그램
- 커널
* 커널은 시스템 호출 인터페이스 아래에 있고 물리적 하드웨어 위에 있는 모든 것으로 구성됨.
* 파일 시스템, CPU 스케줄링, 메모리 관리, 기타 운영 체제 기능을 제공하고 하나의 수준에서 많은 기능을 제공함.
일부 층 구조가 있지만, 완전히 층으로 나뉜 디자인에 엄격하게 따르지는 않음.
Linux System Structure
Monolithic Sturcture에 modular design을 더했다.
운영체제는 여러 레이어로 구분되며, 각 레이어는 하위 레이어 위에 구축된다.
가장 하위 레이어(0)는 하드웨어이고, 가장 높은 레이어(N)은 사용자 인터페이스이다.
모듈화를 통해 각 레이어는 하위 레이어의 기능과 서비스만 사용하도록 선택된다.
각 레이어는 하위 레이어가 제공하는 서비스를 활용하여 독립적으로 작동하고 하위 레이어에서만 사용할 수 있는 기능과 서비스는 사용할 수 없다.
각 레이어는 상위 레이어가 독립적으로 작동하고 수정 및 개선이 가능하며 전체 시스템의 유연성이 높아진다.
Microkernel
마이크로커널은 커널에서 많은 기능을 사용자 영역으로 이전시키는 것을 목표로 한다. ex) Mach - Mac OS X kernel (Darwin)
마이크로커널에서는 사용자 모듈간의 통신이 메시지 패싱으로 이뤄진다.
- 마이크로커널의 확장이 쉬워짐
- 새로운 아키텍처로 운영체제 이식이 쉬워짐
- 더 안정적인 운영체제 (더 적은 코드가 커널 모드에서 실행되므로)
- 보안성이 높다.
- 사용자 영역에서 커널 영역으로 통신하는 성능 오버헤드가 있을 수도 있다.
Modules
현재 많은 운영체제에서는 로드 가능한 커널 모듈을 구현하고 있다.
객체 지향적인 접근 방식을 사용하고, 각 핵심 구성 요소가 분리돼있다.
각 구성 요소는 알려진 인터페이스를 통해 다른 구성 요소와 통신하며, 필요에 따라 커널 내에서 로드할 수 있다.
이러한 구조는 레이어와 비슷하지만 더 유연하다. Linux, Solaris 등에서 로드 가능한 커널 모듈을 사용한다.
Hybrid System
대부분의 현대 운영체제는 하나의 순수한 모델이 아니고, 성능 보안 사용자 요구 사항을 해결하기 위해 여러 접근 방식을 결합한 하이브리드 모델을 사용한다.
Ex)
Linux와 Solaris 커널은 커널 주소 공간 내에서 monolithic 구조를 가지면서 기능을 동적으로 로드하기 위해 모듈화된 구조를 가짐.
Windows는 대부분 monolithic 구조를 가지지만 다른 서브시스템의 개성을 위해 마이크로커널 구조를 사용함.
Mac OS X는 Aqua UI, Cocoa 프로그래밍 환경으로 구성된 레이어 구조를 갖고 있음.
- Mach 마이크로커널, BSD Unix 부분, I/O kit 및 커널 확장이라고 불리는 동적으로 로드 가능한 모듈로 이뤄진 커널 아래에 위치함.
Android
안드로이드는 오픈 핸드셋 얼라이언스에 의해 개발된 오픈소스 운영체제이다.
iOS와 유사한 스택을 갖고 있고, Linux 커널을 기반으로 함.
안드로이드는 프로세스, 메모리, 장치 드라이버 관리를 제공하고 전원 관리 기능을 추가함.
런타인 환경에는 핵심 라이브러리와 ART 가상 머신이 포함돼있고, Java와 안드로이드 API로 개발된 앱이 실행됨.
Java 클래스 파일은 Java 바이트코드로 컴파일되고 이후 ART VM에서 실행 가능한 실행 파일로 번역됨.
안드로이드와 라이브러리는 웹 브라우저(webkit), 데이터베이스(SQLite), 멀티미디어, 작은 libc등의 프레임워크를 포함한다.
구버전은 바이트코드를 기계어로 컴파일하고, (JIT Compilation)
신버전은 앱을 미리 컴파일한다. (AOT Compilation)
System Boot
시스템 전원이 켜지면, 실행은 고정된 메모리 위치에서 시작된다.
하드웨어가 운영체제를 시작할 수 있도록 운영체제는 하드웨어에 제공되어야 한다.
작은 코드 블럭인 부트스트랩 로더, BIOS는 ROM 또는 EEPROM에 저장돼있고 커널을 찾아서 메모리에 로드하고 시작한다.
때로는 부트 블록이 디스크에서 부트스트랩 로더를 로드하는 ROM 코드에 의해 고정 위치에 로드되는 두 단계 프로세스일 수 있다.
현대 시스템에서는 BIOS가 통합 가능한 확장 펌웨어(UEFI)로 대체된다.
부트 로더는 다양한 부팅 상태(단일 사용자 모드 등)와 같은 여러 부팅 상태를 허용한다.
일반적인 부트스트랩 로더인 GRUB는 다중 디스크, 버전, 커널 옵션에서 커널을 선택할 수 있도록 한다.
마지막으로 커널이 로드되면 시스템이 실행된다.
Operating-System Debugging
디버깅은 오류 또는 버그를 찾아서 수정하는 것이고, 성능 튜닝도 포함된다.
운영체제는 오류 정보를 포함하는 로그 파일을 생성한다.
- 응용 프로그램의 실패는 프로세스의 메모리를 캡처하는 코어 덤프 파일을 생성할 수 있다.
- 운영체제의 실패는 커널 메모리를 포함하는 크래스 덤프 파일을 생성할 수 있다.
충돌 외에도 성능 튜닝을 통해 시스템 성능을 최적화할 수 있다.
때로는 분석을 위해 기록된 활동 추적 목록을 사용한다.
프로파일링은 통계적 추세를 찾기 위해 주기적으로 명령 포인터를 샘플링하는 것이다.
성능을 향상시키려면 병목 현상을 제거해야한다. 운영체제는 시스템 동작의 측정 및 표시 수단을 제공해야한다.
top 프로그램이나 windows 작업 관리자 등을 이용해 시스템 자원 사용량, 프로세스 동작, 메모리 사용 등을 모니터링하고 문제를 식별할 수 있다. 이를 통해 시스템 성능을 분석하고 문제를 해결할 수 있다.
Tracing
이벤트별로 데이터를 수집한다. 예를 들어 system calls 호출에 관련된 단계와 같은 것이다.
strace: 프로세스가 호출한 시스템콜을 추적
gdb: 소스 수준 디버거
perf: 성능 도구의 모음
tcpdump: 네트워크 패킷을 수집
BCC
사용자 레벨 및 커널 코드 간 상호작용을 디버깅하는 것은 이를 이해하고 추적하는 도구와 기계적 삽입이 없으면 거의 불가능하다.
BPF(Berkely Packet Filter): 네트워크 데이터를 추적하고 사용자 레벨 및 커널 코드 간의 상호작용을 추적하고 디스크 I/O 활동을 추적할 수 있음.
BCC(BPF Compiler Collection): 리눅스용 추적 기능을 제공하는 다양한 도구를 포함하는 풍부한 툴킷. 사용자 레벨과 커널 코드간의 인터랙션을 추적하고 분석하여 문제를 해결할 수 있음. DTrace도 비슷한 기능을 함.
'학교강의필기장 > 운영체제론' 카테고리의 다른 글
| 운영체제론[6]: 프로세스 간 통신, RPC (0) | 2023.04.24 |
|---|---|
| 운영체제론[5]: 프로세스, 공유메모리와 매시지패싱 (0) | 2023.04.24 |
| 운영체제론[3]: OS 서비스 기능, 시스템콜 (0) | 2023.04.24 |
| 운영체제론[2]: 운영체제론 개요 2 (0) | 2023.04.24 |
| 운영체제론[1]: 운영체제론 개요 1 (0) | 2023.04.24 |
