2.1 사용자를 위한 서비스
- 사용자 인터페이스
- 프로그램 실행
- 입출력 작업
- 파일 시스템 연산
- 통신
- 프로세스 간 정보를 교환
- 정보 교환 방법
- 공유 메모리(Shared Memory) 경유 - 동일 컴퓨터
- 메시지 전송(Meesage Passing) 경유 - 동일/다른 컴퓨터
- 오류 탐지
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 시스템 정지
- 오류 발생 프로세스 종료 - 오류코드 반환
- 오류 원인 제거 후 재실행
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 자원 할당
- 회계
- 보호와 보안
====================================
2.2 사용자 운영체제 인터페이스
- 명령어 해석 - command line interface(CLI)
- command를 입력 받아서 수행
- 구현 방법
- 커널에 포함되어 구현, 또는 작업이 시작되거나, 로그온할 때에 대화형으로 수행되는 특수한 (시스템) 프로그램으로 구현
- 명령어 처리의 구현
- 내장 명령어
- 유틸리티 명령어
- 시스템 관리자, 파워 유저가 많이 사용 - 작업에 빨리 접근, 효울적
- 프로그램 기능이 있어서 반복적 작업에 효과적 → 셸 스크립트
- 그래픽 사용자 인터페이스 (GUI)
- 사용하기 쉬움
- 사용자 인터페이스는 대개 OS의 직접적인 기능이 아님
- 대게, 운영체제 시스템 구조에 포함되지 않음
====================================
2.3 시스템 호출(System Call)
- 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공
- 운영체제 프로그래밍 인터페이스
- 대개 C/C++와 같은 고급 언어 루틴 형태로 제공
- 프로그래머가 시스템 호출에 대한 C/C++ 함수를 호출하여 사용
- 서비스를 수행하는 저수준의 작업은 시스템호출 명령어를 포함하는 어셈블리 코드를 포함하여 작성됨
- MS-DOS는 시스템 호출 명령어를 사용하는 어셈블리언어 프로그램으로 운영체제 서비스를 요청하도록 되어있음
- 응용 프로그래밍 인터페이스 (API)
- 응용 프로그래머에서 사용 가능한 함수의 집합을 지정 (라이브러리 형태)
- 시스템 호출보다 API를 더 많이 사용하는 이유
- 프로그램 이식성
- 사용하기 쉬움
- 시스템 호출의 구현
- 각 시스템 호출에 번호가 부여됨
- 시스템 호출 인터페이스
- 매개 변수 전달 받음
- 관련된 시스템 호출을 호출
- status와 반환 값 반환
- 운영체제 인터페이스의 상세 내용은 API에 의해서 숨겨짐 → 사용자는 API 매개변수 규칙을 준수하고, 시스템 호출의 결과로 OS가 수행하는 작업에 대해서 이해하면 됨
- 시스템 호출 매개변수 전달
====================================
2.4 시스템 호출의 유형
- 시스템 호출의 중요 범주
- 프로세스 제어
- 프로세스 생성/적재/실행/종료, 중지
- 속성 읽기/설정, 메모리 할당/반납
- 시간,사건 대기, 사건 알림
- 파일 관리
- 파일 생성, 삭제, 열기, 닫기 등
- 속성 읽기/설정
- 장치 관리
- 장치 요구, 반납, 읽기, 쓰기, 위치 변경
- 속성 읽기/설정, 논리적 부착/분리
- 정보 유지보수
- 통신
- 통신 연결 생성/삭제
- 메시지 송신, 수신, 상태 정보 전달
- 원격 장치 부착/분리
- 보호
- 네트워크와 인터넷 연결로 모든 컴퓨터 시스템에서 보호를 고려해야
- 프로세스 제어
- single-tasking 시스템: MS-DOS
- single-tasking 시스템: Arduino
- multi-tasking 시스템: UNIX/Linux
====================================
2.5 시스템 프로그램
- 프로그램 개발과 실행을 위해 편리한 환경을 제공하는 프로그렘
====================================
2.6 운영체제 설계와 구현
- 설계 목표와 명세 정의
- 요구조건 지정 (설게 목표)
- 사용자 목표
- 시스템 목표
- 요구 조건은 애매하고 다양하게 해석될 수 있으며, 일반적으로 합의된 유일한 해법은 없음
- 운영체제의 설계 및 구현
- 모든 요구 조건을 해결하는 완전한 해결책은 없지만, 다양한 요구 조건에 대한 성공이 입증된 다양한 접근법은 있다.
- 소프트웨어 공학에서 개발된 일반적인 원칙 사용
- 내부 구조는 운영체제마다 다를 수 있음
- 기법(Mechanism)과 정책(Policy)
- 중요한 설계 원칙: 기법과 정책의 분리
- 기법: 어떻게 할 것인가? (How)
- 정책 변경에 민감하지 않는 일반적인 것이 바람직
- 정책: 무엇을 할 것인가? (What)
- 시간이 지남에 따라서 변경될 수 있음
- e.g. CPU 보호 방법
- 기법: CPU 보호를 위하여 타이머 구조 사용
- 정책: 특정 사용자를 위한 타이머 양 결정
- 기법과 정책의 분리는 flexibility를 위해서 중요
- 구현(Implementation)
- 운영체제의 구현
- 초기에는 어셈블리 언어로 작성
- 현재 대부분은 고급 언어로 작성
- system programs의 구현
- C, C++ 등 으로 작성됨
- 운영체제의 구현
- 고급 언어 구현의 장단점
- 장점
- 코드를 빠르게 작성
- 간결한 코드
- 이해와 디버깅이 쉬움
- 이식하기 훨씬 쉬움
- 단점이 문제가 안 되는 이유
- 컴파일러가 최적화 됨
- OS의 주된 성능 향상은 더 좋은 자료구조와 알고리즘에 의한 것
- 고성능이 중요한 소량의 코드만 어셈블리 코드로 대체
- 장점
====================================
2.7 운영체제 구조
- Simple Structure (단층 구조)
- monolithic 구조 - 많은 기능들이 하나의 계층
- 많은 상용 운영체제, 잘 정의된 구조를 갖지 않음
- MS-DOS
- UNIX
- Layered Structure (계층 구조)
- 운영체제가 여러 계층으로 구분
- 각 계층은 하위 계층 위에 구축됨
- 장점 - 구현과 디버깅이 간단, 하위계층 연산이 어떻게 구현되어 있는지 알 필요 X, 무슨 동작만 하는지 알면 됨 ex) 네트워크 프로토콜, 웹 구현
- 단점 - 각 계층을 적절히 정의하는 것이 어렵고, 명확하지 않을 수 있음, 덜 효율적, 요즘 부정적
- Microkernel
- 필수적이 아닌 많은 부분을 사용자 공간으로 이동 → Small Kernel
- 개발 이유: UNIX 커널 확장되면서 관리 어려움
- 장점: 확장 용이, 운영체제 이식 용이, 높은 신뢰성과 보안성
- 단점: 시스템 함수 오버헤드로 인한 성능 저하
- 기본 기능
- 사용자 모듈과 사용자 공간에서 수행하는 서비스 간에 통신 기능 제공 → Message Passing 사용
- Modules
- kernel 구성
- a set of core components + loadable kernel modules
- loadable kernel module (LKM)
- 부팅 또는 실행시간 동안 동적으로 적재되어 커널 기능 확장
- 대부분 현대 운영체제에서 구현됨
- 모듈 인터페이스의 특징
- 각 core component가 분리됨
- 알려진 인터페이스를 통하여 다른 component/module과 통신
- layered 구조와 유사하지만 더 유연성 있음
- microkenel approach와 유사하지만 더 효율
- kernel 구성
====================================
2.8 운영체제 디버깅
- 장애 분석
- log file - 프로세스가 실패하면 오류 정보를 기록
- core dump - 오류 발생 프로세스의 메모리 저장
- crash dump - 커널 장애→커널 메모리 내용 저장
- 성능 조정도 디버깅 작업에 포함
- 병목 지점을 제거하여 시스템 성능 최적화 가능
- 추적
- dtrace
- strace
====================================
2.10 시스템 부트
- Bootstarpping(booting)
- 커널을 적재하여 컴퓨터 시작하는 절차
- Bootstrap loader
- 커널을 찾아서 메모리에 적재하고 수행을 시작하는 일, ROM에 저장된 코드
- 시스템 진단 작업 수행, 전체 초기화 후 운영체제 시작시킴
- Firmware
- bootstarp 코드 변경 가능을 위해 ROM 대신 EPROM에 저장
- 하드웨어와 소프트웨어의 중간 특성
- RAM에서 실행하는 거보다 느려서 RAM에 복사하여 실행
- 보통 운영체제는 디스크에 저장하지만, 일부 시스템(smartphone, game console)은 EPROM/flash 저장
- 시스템 부트 과정
2.1 사용자를 위한 서비스
- 사용자 인터페이스
- 프로그램 실행
- 입출력 작업
- 파일 시스템 연산
- 통신
- 프로세스 간 정보를 교환
- 정보 교환 방법
- 공유 메모리(Shared Memory) 경유 - 동일 컴퓨터
- 메시지 전송(Meesage Passing) 경유 - 동일/다른 컴퓨터
- 오류 탐지
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 시스템 정지
- 오류 발생 프로세스 종료 - 오류코드 반환
- 오류 원인 제거 후 재실행
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 자원 할당
- 회계
- 보호와 보안
- 명령어 해석 - command line interface(CLI)
- command를 입력 받아서 수행
- 구현 방법
- 커널에 포함되어 구현, 또는 작업이 시작되거나, 로그온할 때에 대화형으로 수행되는 특수한 (시스템) 프로그램으로 구현
- 명령어 처리의 구현
- 내장 명령어
- 유틸리티 명령어
- 시스템 관리자, 파워 유저가 많이 사용 - 작업에 빨리 접근, 효울적
- 프로그램 기능이 있어서 반복적 작업에 효과적 → 셸 스크립트
- 그래픽 사용자 인터페이스 (GUI)
- 사용하기 쉬움
- 사용자 인터페이스는 대개 OS의 직접적인 기능이 아님
- 대게, 운영체제 시스템 구조에 포함되지 않음
- 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공
- 운영체제 프로그래밍 인터페이스
- 대개 C/C++와 같은 고급 언어 루틴 형태로 제공
- 프로그래머가 시스템 호출에 대한 C/C++ 함수를 호출하여 사용
- 서비스를 수행하는 저수준의 작업은 시스템호출 명령어를 포함하는 어셈블리 코드를 포함하여 작성됨
- MS-DOS는 시스템 호출 명령어를 사용하는 어셈블리언어 프로그램으로 운영체제 서비스를 요청하도록 되어있음
- 응용 프로그래밍 인터페이스 (API)
- 응용 프로그래머에서 사용 가능한 함수의 집합을 지정 (라이브러리 형태)
- 시스템 호출보다 API를 더 많이 사용하는 이유
- 프로그램 이식성
- 사용하기 쉬움
- 시스템 호출의 구현
- 각 시스템 호출에 번호가 부여됨
- 시스템 호출 인터페이스
- 매개 변수 전달 받음
- 관련된 시스템 호출을 호출
- status와 반환 값 반환
- 운영체제 인터페이스의 상세 내용은 API에 의해서 숨겨짐 → 사용자는 API 매개변수 규칙을 준수하고, 시스템 호출의 결과로 OS가 수행하는 작업에 대해서 이해하면 됨
- 시스템 호출 매개변수 전달
- 시스템 호출의 중요 범주
- 프로세스 제어
- 프로세스 생성/적재/실행/종료, 중지
- 속성 읽기/설정, 메모리 할당/반납
- 시간,사건 대기, 사건 알림
- 파일 관리
- 파일 생성, 삭제, 열기, 닫기 등
- 속성 읽기/설정
- 장치 관리
- 장치 요구, 반납, 읽기, 쓰기, 위치 변경
- 속성 읽기/설정, 논리적 부착/분리
- 정보 유지보수
- 통신
- 통신 연결 생성/삭제
- 메시지 송신, 수신, 상태 정보 전달
- 원격 장치 부착/분리
- 보호
- 네트워크와 인터넷 연결로 모든 컴퓨터 시스템에서 보호를 고려해야
- 프로세스 제어
- single-tasking 시스템: MS-DOS
- single-tasking 시스템: Arduino
- multi-tasking 시스템: UNIX/Linux
- 프로그램 개발과 실행을 위해 편리한 환경을 제공하는 프로그렘
- 설계 목표와 명세 정의
- 요구조건 지정 (설게 목표)
- 사용자 목표
- 시스템 목표
- 요구 조건은 애매하고 다양하게 해석될 수 있으며, 일반적으로 합의된 유일한 해법은 없음
- 운영체제의 설계 및 구현
- 모든 요구 조건을 해결하는 완전한 해결책은 없지만, 다양한 요구 조건에 대한 성공이 입증된 다양한 접근법은 있다.
- 소프트웨어 공학에서 개발된 일반적인 원칙 사용
- 내부 구조는 운영체제마다 다를 수 있음
- 기법(Mechanism)과 정책(Policy)
- 중요한 설계 원칙: 기법과 정책의 분리
- 기법: 어떻게 할 것인가? (How)
- 정책 변경에 민감하지 않는 일반적인 것이 바람직
- 정책: 무엇을 할 것인가? (What)
- 시간이 지남에 따라서 변경될 수 있음
- e.g. CPU 보호 방법
- 기법: CPU 보호를 위하여 타이머 구조 사용
- 정책: 특정 사용자를 위한 타이머 양 결정
- 기법과 정책의 분리는 flexibility를 위해서 중요
- 구현(Implementation)
- 운영체제의 구현
- 초기에는 어셈블리 언어로 작성
- 현재 대부분은 고급 언어로 작성
- system programs의 구현
- C, C++ 등 으로 작성됨
- 운영체제의 구현
- 고급 언어 구현의 장단점
- 장점
- 코드를 빠르게 작성
- 간결한 코드
- 이해와 디버깅이 쉬움
- 이식하기 훨씬 쉬움
- 단점이 문제가 안 되는 이유
- 컴파일러가 최적화 됨
- OS의 주된 성능 향상은 더 좋은 자료구조와 알고리즘에 의한 것
- 고성능이 중요한 소량의 코드만 어셈블리 코드로 대체
- 장점
- Simple Structure (단층 구조)
- monolithic 구조 - 많은 기능들이 하나의 계층
- 많은 상용 운영체제, 잘 정의된 구조를 갖지 않음
- MS-DOS
- UNIX
- Layered Structure (계층 구조)
- 운영체제가 여러 계층으로 구분
- 각 계층은 하위 계층 위에 구축됨
- 장점 - 구현과 디버깅이 간단, 하위계층 연산이 어떻게 구현되어 있는지 알 필요 X, 무슨 동작만 하는지 알면 됨 ex) 네트워크 프로토콜, 웹 구현
- 단점 - 각 계층을 적절히 정의하는 것이 어렵고, 명확하지 않을 수 있음, 덜 효율적, 요즘 부정적
- Microkernel
- 필수적이 아닌 많은 부분을 사용자 공간으로 이동 → Small Kernel
- 개발 이유: UNIX 커널 확장되면서 관리 어려움
- 장점: 확장 용이, 운영체제 이식 용이, 높은 신뢰성과 보안성
- 단점: 시스템 함수 오버헤드로 인한 성능 저하
- 기본 기능
- 사용자 모듈과 사용자 공간에서 수행하는 서비스 간에 통신 기능 제공 → Message Passing 사용
- Modules
- kernel 구성
- a set of core components + loadable kernel modules
- loadable kernel module (LKM)
- 부팅 또는 실행시간 동안 동적으로 적재되어 커널 기능 확장
- 대부분 현대 운영체제에서 구현됨
- 모듈 인터페이스의 특징
- 각 core component가 분리됨
- 알려진 인터페이스를 통하여 다른 component/module과 통신
- layered 구조와 유사하지만 더 유연성 있음
- microkenel approach와 유사하지만 더 효율
- kernel 구성
- 장애 분석
- log file - 프로세스가 실패하면 오류 정보를 기록
- core dump - 오류 발생 프로세스의 메모리 저장
- crash dump - 커널 장애→커널 메모리 내용 저장
- 성능 조정도 디버깅 작업에 포함
- 병목 지점을 제거하여 시스템 성능 최적화 가능
- 추적
- dtrace
- strace
- Bootstarpping(booting)
- 커널을 적재하여 컴퓨터 시작하는 절차
- Bootstrap loader
- 커널을 찾아서 메모리에 적재하고 수행을 시작하는 일, ROM에 저장된 코드
- 시스템 진단 작업 수행, 전체 초기화 후 운영체제 시작시킴
- Firmware
- bootstarp 코드 변경 가능을 위해 ROM 대신 EPROM에 저장
- 하드웨어와 소프트웨어의 중간 특성
- RAM에서 실행하는 거보다 느려서 RAM에 복사하여 실행
- 보통 운영체제는 디스크에 저장하지만, 일부 시스템(smartphone, game console)은 EPROM/flash 저장
- 시스템 부트 과정
- 2.1 사용자를 위한 서비스
- 사용자 인터페이스
- 프로그램 실행
- 입출력 작업
- 파일 시스템 연산
- 통신
- 프로세스 간 정보를 교환
- 정보 교환 방법
- 공유 메모리(Shared Memory) 경유 - 동일 컴퓨터
- 메시지 전송(Meesage Passing) 경유 - 동일/다른 컴퓨터
- 오류 탐지
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 시스템 정지
- 오류 발생 프로세스 종료 - 오류코드 반환
- 오류 원인 제거 후 재실행
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 자원 할당
- 회계
- 보호와 보안
- 명령어 해석 - command line interface(CLI)
- command를 입력 받아서 수행
- 구현 방법
- 커널에 포함되어 구현, 또는 작업이 시작되거나, 로그온할 때에 대화형으로 수행되는 특수한 (시스템) 프로그램으로 구현
- 명령어 처리의 구현
- 내장 명령어
- 유틸리티 명령어
- 시스템 관리자, 파워 유저가 많이 사용 - 작업에 빨리 접근, 효울적
- 프로그램 기능이 있어서 반복적 작업에 효과적 → 셸 스크립트
- 그래픽 사용자 인터페이스 (GUI)
- 사용하기 쉬움
- 사용자 인터페이스는 대개 OS의 직접적인 기능이 아님
- 대게, 운영체제 시스템 구조에 포함되지 않음
- 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공
- 운영체제 프로그래밍 인터페이스
- 대개 C/C++와 같은 고급 언어 루틴 형태로 제공
- 프로그래머가 시스템 호출에 대한 C/C++ 함수를 호출하여 사용
- 서비스를 수행하는 저수준의 작업은 시스템호출 명령어를 포함하는 어셈블리 코드를 포함하여 작성됨
- MS-DOS는 시스템 호출 명령어를 사용하는 어셈블리언어 프로그램으로 운영체제 서비스를 요청하도록 되어있음
- 응용 프로그래밍 인터페이스 (API)
- 응용 프로그래머에서 사용 가능한 함수의 집합을 지정 (라이브러리 형태)
- 시스템 호출보다 API를 더 많이 사용하는 이유
- 프로그램 이식성
- 사용하기 쉬움
- 시스템 호출의 구현
- 각 시스템 호출에 번호가 부여됨
- 시스템 호출 인터페이스
- 매개 변수 전달 받음
- 관련된 시스템 호출을 호출
- status와 반환 값 반환
- 운영체제 인터페이스의 상세 내용은 API에 의해서 숨겨짐 → 사용자는 API 매개변수 규칙을 준수하고, 시스템 호출의 결과로 OS가 수행하는 작업에 대해서 이해하면 됨
- 시스템 호출 매개변수 전달
- 시스템 호출의 중요 범주
- 프로세스 제어
- 프로세스 생성/적재/실행/종료, 중지
- 속성 읽기/설정, 메모리 할당/반납
- 시간,사건 대기, 사건 알림
- 파일 관리
- 파일 생성, 삭제, 열기, 닫기 등
- 속성 읽기/설정
- 장치 관리
- 장치 요구, 반납, 읽기, 쓰기, 위치 변경
- 속성 읽기/설정, 논리적 부착/분리
- 정보 유지보수
- 통신
- 통신 연결 생성/삭제
- 메시지 송신, 수신, 상태 정보 전달
- 원격 장치 부착/분리
- 보호
- 네트워크와 인터넷 연결로 모든 컴퓨터 시스템에서 보호를 고려해야
- 프로세스 제어
- single-tasking 시스템: MS-DOS
- single-tasking 시스템: Arduino
- multi-tasking 시스템: UNIX/Linux
- 프로그램 개발과 실행을 위해 편리한 환경을 제공하는 프로그렘
- 설계 목표와 명세 정의
- 요구조건 지정 (설게 목표)
- 사용자 목표
- 시스템 목표
- 요구 조건은 애매하고 다양하게 해석될 수 있으며, 일반적으로 합의된 유일한 해법은 없음
- 운영체제의 설계 및 구현
- 모든 요구 조건을 해결하는 완전한 해결책은 없지만, 다양한 요구 조건에 대한 성공이 입증된 다양한 접근법은 있다.
- 소프트웨어 공학에서 개발된 일반적인 원칙 사용
- 내부 구조는 운영체제마다 다를 수 있음
- 기법(Mechanism)과 정책(Policy)
- 중요한 설계 원칙: 기법과 정책의 분리
- 기법: 어떻게 할 것인가? (How)
- 정책 변경에 민감하지 않는 일반적인 것이 바람직
- 정책: 무엇을 할 것인가? (What)
- 시간이 지남에 따라서 변경될 수 있음
- e.g. CPU 보호 방법
- 기법: CPU 보호를 위하여 타이머 구조 사용
- 정책: 특정 사용자를 위한 타이머 양 결정
- 기법과 정책의 분리는 flexibility를 위해서 중요
- 구현(Implementation)
- 운영체제의 구현
- 초기에는 어셈블리 언어로 작성
- 현재 대부분은 고급 언어로 작성
- system programs의 구현
- C, C++ 등 으로 작성됨
- 운영체제의 구현
- 고급 언어 구현의 장단점
- 장점
- 코드를 빠르게 작성
- 간결한 코드
- 이해와 디버깅이 쉬움
- 이식하기 훨씬 쉬움
- 단점이 문제가 안 되는 이유
- 컴파일러가 최적화 됨
- OS의 주된 성능 향상은 더 좋은 자료구조와 알고리즘에 의한 것
- 고성능이 중요한 소량의 코드만 어셈블리 코드로 대체
- 장점
- Simple Structure (단층 구조)
- monolithic 구조 - 많은 기능들이 하나의 계층
- 많은 상용 운영체제, 잘 정의된 구조를 갖지 않음
- MS-DOS
- UNIX
- Layered Structure (계층 구조)
- 운영체제가 여러 계층으로 구분
- 각 계층은 하위 계층 위에 구축됨
- 장점 - 구현과 디버깅이 간단, 하위계층 연산이 어떻게 구현되어 있는지 알 필요 X, 무슨 동작만 하는지 알면 됨 ex) 네트워크 프로토콜, 웹 구현
- 단점 - 각 계층을 적절히 정의하는 것이 어렵고, 명확하지 않을 수 있음, 덜 효율적, 요즘 부정적
- Microkernel
- 필수적이 아닌 많은 부분을 사용자 공간으로 이동 → Small Kernel
- 개발 이유: UNIX 커널 확장되면서 관리 어려움
- 장점: 확장 용이, 운영체제 이식 용이, 높은 신뢰성과 보안성
- 단점: 시스템 함수 오버헤드로 인한 성능 저하
- 기본 기능
- 사용자 모듈과 사용자 공간에서 수행하는 서비스 간에 통신 기능 제공 → Message Passing 사용
- Modules
- kernel 구성
- a set of core components + loadable kernel modules
- loadable kernel module (LKM)
- 부팅 또는 실행시간 동안 동적으로 적재되어 커널 기능 확장
- 대부분 현대 운영체제에서 구현됨
- 모듈 인터페이스의 특징
- 각 core component가 분리됨
- 알려진 인터페이스를 통하여 다른 component/module과 통신
- layered 구조와 유사하지만 더 유연성 있음
- microkenel approach와 유사하지만 더 효율
- kernel 구성
- 장애 분석
- log file - 프로세스가 실패하면 오류 정보를 기록
- core dump - 오류 발생 프로세스의 메모리 저장
- crash dump - 커널 장애→커널 메모리 내용 저장
- 성능 조정도 디버깅 작업에 포함
- 병목 지점을 제거하여 시스템 성능 최적화 가능
- 추적
- dtrace
- strace
- Bootstarpping(booting)
- 커널을 적재하여 컴퓨터 시작하는 절차
- Bootstrap loader
- 커널을 찾아서 메모리에 적재하고 수행을 시작하는 일, ROM에 저장된 코드
- 시스템 진단 작업 수행, 전체 초기화 후 운영체제 시작시킴
- Firmware
- bootstarp 코드 변경 가능을 위해 ROM 대신 EPROM에 저장
- 하드웨어와 소프트웨어의 중간 특성
- RAM에서 실행하는 거보다 느려서 RAM에 복사하여 실행
- 보통 운영체제는 디스크에 저장하지만, 일부 시스템(smartphone, game console)은 EPROM/flash 저장
- 시스템 부트 과정
- 2.1 사용자를 위한 서비스
- 사용자 인터페이스
- 프로그램 실행
- 입출력 작업
- 파일 시스템 연산
- 통신
- 프로세스 간 정보를 교환
- 정보 교환 방법
- 공유 메모리(Shared Memory) 경유 - 동일 컴퓨터
- 메시지 전송(Meesage Passing) 경유 - 동일/다른 컴퓨터
- 오류 탐지
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 시스템 정지
- 오류 발생 프로세스 종료 - 오류코드 반환
- 오류 원인 제거 후 재실행
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 자원 할당
- 회계
- 보호와 보안
- 명령어 해석 - command line interface(CLI)
- command를 입력 받아서 수행
- 구현 방법
- 커널에 포함되어 구현, 또는 작업이 시작되거나, 로그온할 때에 대화형으로 수행되는 특수한 (시스템) 프로그램으로 구현
- 명령어 처리의 구현
- 내장 명령어
- 유틸리티 명령어
- 시스템 관리자, 파워 유저가 많이 사용 - 작업에 빨리 접근, 효울적
- 프로그램 기능이 있어서 반복적 작업에 효과적 → 셸 스크립트
- 그래픽 사용자 인터페이스 (GUI)
- 사용하기 쉬움
- 사용자 인터페이스는 대개 OS의 직접적인 기능이 아님
- 대게, 운영체제 시스템 구조에 포함되지 않음
- 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공
- 운영체제 프로그래밍 인터페이스
- 대개 C/C++와 같은 고급 언어 루틴 형태로 제공
- 프로그래머가 시스템 호출에 대한 C/C++ 함수를 호출하여 사용
- 서비스를 수행하는 저수준의 작업은 시스템호출 명령어를 포함하는 어셈블리 코드를 포함하여 작성됨
- MS-DOS는 시스템 호출 명령어를 사용하는 어셈블리언어 프로그램으로 운영체제 서비스를 요청하도록 되어있음
- 응용 프로그래밍 인터페이스 (API)
- 응용 프로그래머에서 사용 가능한 함수의 집합을 지정 (라이브러리 형태)
- 시스템 호출보다 API를 더 많이 사용하는 이유
- 프로그램 이식성
- 사용하기 쉬움
- 시스템 호출의 구현
- 각 시스템 호출에 번호가 부여됨
- 시스템 호출 인터페이스
- 매개 변수 전달 받음
- 관련된 시스템 호출을 호출
- status와 반환 값 반환
- 운영체제 인터페이스의 상세 내용은 API에 의해서 숨겨짐 → 사용자는 API 매개변수 규칙을 준수하고, 시스템 호출의 결과로 OS가 수행하는 작업에 대해서 이해하면 됨
- 시스템 호출 매개변수 전달
- 시스템 호출의 중요 범주
- 프로세스 제어
- 프로세스 생성/적재/실행/종료, 중지
- 속성 읽기/설정, 메모리 할당/반납
- 시간,사건 대기, 사건 알림
- 파일 관리
- 파일 생성, 삭제, 열기, 닫기 등
- 속성 읽기/설정
- 장치 관리
- 장치 요구, 반납, 읽기, 쓰기, 위치 변경
- 속성 읽기/설정, 논리적 부착/분리
- 정보 유지보수
- 통신
- 통신 연결 생성/삭제
- 메시지 송신, 수신, 상태 정보 전달
- 원격 장치 부착/분리
- 보호
- 네트워크와 인터넷 연결로 모든 컴퓨터 시스템에서 보호를 고려해야
- 프로세스 제어
- single-tasking 시스템: MS-DOS
- single-tasking 시스템: Arduino
- multi-tasking 시스템: UNIX/Linux
- 프로그램 개발과 실행을 위해 편리한 환경을 제공하는 프로그렘
- 설계 목표와 명세 정의
- 요구조건 지정 (설게 목표)
- 사용자 목표
- 시스템 목표
- 요구 조건은 애매하고 다양하게 해석될 수 있으며, 일반적으로 합의된 유일한 해법은 없음
- 운영체제의 설계 및 구현
- 모든 요구 조건을 해결하는 완전한 해결책은 없지만, 다양한 요구 조건에 대한 성공이 입증된 다양한 접근법은 있다.
- 소프트웨어 공학에서 개발된 일반적인 원칙 사용
- 내부 구조는 운영체제마다 다를 수 있음
- 기법(Mechanism)과 정책(Policy)
- 중요한 설계 원칙: 기법과 정책의 분리
- 기법: 어떻게 할 것인가? (How)
- 정책 변경에 민감하지 않는 일반적인 것이 바람직
- 정책: 무엇을 할 것인가? (What)
- 시간이 지남에 따라서 변경될 수 있음
- e.g. CPU 보호 방법
- 기법: CPU 보호를 위하여 타이머 구조 사용
- 정책: 특정 사용자를 위한 타이머 양 결정
- 기법과 정책의 분리는 flexibility를 위해서 중요
- 구현(Implementation)
- 운영체제의 구현
- 초기에는 어셈블리 언어로 작성
- 현재 대부분은 고급 언어로 작성
- system programs의 구현
- C, C++ 등 으로 작성됨
- 운영체제의 구현
- 고급 언어 구현의 장단점
- 장점
- 코드를 빠르게 작성
- 간결한 코드
- 이해와 디버깅이 쉬움
- 이식하기 훨씬 쉬움
- 단점이 문제가 안 되는 이유
- 컴파일러가 최적화 됨
- OS의 주된 성능 향상은 더 좋은 자료구조와 알고리즘에 의한 것
- 고성능이 중요한 소량의 코드만 어셈블리 코드로 대체
- 장점
- Simple Structure (단층 구조)
- monolithic 구조 - 많은 기능들이 하나의 계층
- 많은 상용 운영체제, 잘 정의된 구조를 갖지 않음
- MS-DOS
- UNIX
- Layered Structure (계층 구조)
- 운영체제가 여러 계층으로 구분
- 각 계층은 하위 계층 위에 구축됨
- 장점 - 구현과 디버깅이 간단, 하위계층 연산이 어떻게 구현되어 있는지 알 필요 X, 무슨 동작만 하는지 알면 됨 ex) 네트워크 프로토콜, 웹 구현
- 단점 - 각 계층을 적절히 정의하는 것이 어렵고, 명확하지 않을 수 있음, 덜 효율적, 요즘 부정적
- Microkernel
- 필수적이 아닌 많은 부분을 사용자 공간으로 이동 → Small Kernel
- 개발 이유: UNIX 커널 확장되면서 관리 어려움
- 장점: 확장 용이, 운영체제 이식 용이, 높은 신뢰성과 보안성
- 단점: 시스템 함수 오버헤드로 인한 성능 저하
- 기본 기능
- 사용자 모듈과 사용자 공간에서 수행하는 서비스 간에 통신 기능 제공 → Message Passing 사용
- Modules
- kernel 구성
- a set of core components + loadable kernel modules
- loadable kernel module (LKM)
- 부팅 또는 실행시간 동안 동적으로 적재되어 커널 기능 확장
- 대부분 현대 운영체제에서 구현됨
- 모듈 인터페이스의 특징
- 각 core component가 분리됨
- 알려진 인터페이스를 통하여 다른 component/module과 통신
- layered 구조와 유사하지만 더 유연성 있음
- microkenel approach와 유사하지만 더 효율
- kernel 구성
- 장애 분석
- log file - 프로세스가 실패하면 오류 정보를 기록
- core dump - 오류 발생 프로세스의 메모리 저장
- crash dump - 커널 장애→커널 메모리 내용 저장
- 성능 조정도 디버깅 작업에 포함
- 병목 지점을 제거하여 시스템 성능 최적화 가능
- 추적
- dtrace
- strace
- Bootstarpping(booting)
- 커널을 적재하여 컴퓨터 시작하는 절차
- Bootstrap loader
- 커널을 찾아서 메모리에 적재하고 수행을 시작하는 일, ROM에 저장된 코드
- 시스템 진단 작업 수행, 전체 초기화 후 운영체제 시작시킴
- Firmware
- bootstarp 코드 변경 가능을 위해 ROM 대신 EPROM에 저장
- 하드웨어와 소프트웨어의 중간 특성
- RAM에서 실행하는 거보다 느려서 RAM에 복사하여 실행
- 보통 운영체제는 디스크에 저장하지만, 일부 시스템(smartphone, game console)은 EPROM/flash 저장
- 시스템 부트 과정
- 2.1 사용자를 위한 서비스
- 사용자 인터페이스
- 프로그램 실행
- 입출력 작업
- 파일 시스템 연산
- 통신
- 프로세스 간 정보를 교환
- 정보 교환 방법
- 공유 메모리(Shared Memory) 경유 - 동일 컴퓨터
- 메시지 전송(Meesage Passing) 경유 - 동일/다른 컴퓨터
- 오류 탐지
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 시스템 정지
- 오류 발생 프로세스 종료 - 오류코드 반환
- 오류 원인 제거 후 재실행
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 자원 할당
- 회계
- 보호와 보안
- 명령어 해석 - command line interface(CLI)
- command를 입력 받아서 수행
- 구현 방법
- 커널에 포함되어 구현, 또는 작업이 시작되거나, 로그온할 때에 대화형으로 수행되는 특수한 (시스템) 프로그램으로 구현
- 명령어 처리의 구현
- 내장 명령어
- 유틸리티 명령어
- 시스템 관리자, 파워 유저가 많이 사용 - 작업에 빨리 접근, 효울적
- 프로그램 기능이 있어서 반복적 작업에 효과적 → 셸 스크립트
- 그래픽 사용자 인터페이스 (GUI)
- 사용하기 쉬움
- 사용자 인터페이스는 대개 OS의 직접적인 기능이 아님
- 대게, 운영체제 시스템 구조에 포함되지 않음
- 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공
- 운영체제 프로그래밍 인터페이스
- 대개 C/C++와 같은 고급 언어 루틴 형태로 제공
- 프로그래머가 시스템 호출에 대한 C/C++ 함수를 호출하여 사용
- 서비스를 수행하는 저수준의 작업은 시스템호출 명령어를 포함하는 어셈블리 코드를 포함하여 작성됨
- MS-DOS는 시스템 호출 명령어를 사용하는 어셈블리언어 프로그램으로 운영체제 서비스를 요청하도록 되어있음
- 응용 프로그래밍 인터페이스 (API)
- 응용 프로그래머에서 사용 가능한 함수의 집합을 지정 (라이브러리 형태)
- 시스템 호출보다 API를 더 많이 사용하는 이유
- 프로그램 이식성
- 사용하기 쉬움
- 시스템 호출의 구현
- 각 시스템 호출에 번호가 부여됨
- 시스템 호출 인터페이스
- 매개 변수 전달 받음
- 관련된 시스템 호출을 호출
- status와 반환 값 반환
- 운영체제 인터페이스의 상세 내용은 API에 의해서 숨겨짐 → 사용자는 API 매개변수 규칙을 준수하고, 시스템 호출의 결과로 OS가 수행하는 작업에 대해서 이해하면 됨
- 시스템 호출 매개변수 전달
- 시스템 호출의 중요 범주
- 프로세스 제어
- 프로세스 생성/적재/실행/종료, 중지
- 속성 읽기/설정, 메모리 할당/반납
- 시간,사건 대기, 사건 알림
- 파일 관리
- 파일 생성, 삭제, 열기, 닫기 등
- 속성 읽기/설정
- 장치 관리
- 장치 요구, 반납, 읽기, 쓰기, 위치 변경
- 속성 읽기/설정, 논리적 부착/분리
- 정보 유지보수
- 통신
- 통신 연결 생성/삭제
- 메시지 송신, 수신, 상태 정보 전달
- 원격 장치 부착/분리
- 보호
- 네트워크와 인터넷 연결로 모든 컴퓨터 시스템에서 보호를 고려해야
- 프로세스 제어
- single-tasking 시스템: MS-DOS
- single-tasking 시스템: Arduino
- multi-tasking 시스템: UNIX/Linux
- 프로그램 개발과 실행을 위해 편리한 환경을 제공하는 프로그렘
- 설계 목표와 명세 정의
- 요구조건 지정 (설게 목표)
- 사용자 목표
- 시스템 목표
- 요구 조건은 애매하고 다양하게 해석될 수 있으며, 일반적으로 합의된 유일한 해법은 없음
- 운영체제의 설계 및 구현
- 모든 요구 조건을 해결하는 완전한 해결책은 없지만, 다양한 요구 조건에 대한 성공이 입증된 다양한 접근법은 있다.
- 소프트웨어 공학에서 개발된 일반적인 원칙 사용
- 내부 구조는 운영체제마다 다를 수 있음
- 기법(Mechanism)과 정책(Policy)
- 중요한 설계 원칙: 기법과 정책의 분리
- 기법: 어떻게 할 것인가? (How)
- 정책 변경에 민감하지 않는 일반적인 것이 바람직
- 정책: 무엇을 할 것인가? (What)
- 시간이 지남에 따라서 변경될 수 있음
- e.g. CPU 보호 방법
- 기법: CPU 보호를 위하여 타이머 구조 사용
- 정책: 특정 사용자를 위한 타이머 양 결정
- 기법과 정책의 분리는 flexibility를 위해서 중요
- 구현(Implementation)
- 운영체제의 구현
- 초기에는 어셈블리 언어로 작성
- 현재 대부분은 고급 언어로 작성
- system programs의 구현
- C, C++ 등 으로 작성됨
- 운영체제의 구현
- 고급 언어 구현의 장단점
- 장점
- 코드를 빠르게 작성
- 간결한 코드
- 이해와 디버깅이 쉬움
- 이식하기 훨씬 쉬움
- 단점이 문제가 안 되는 이유
- 컴파일러가 최적화 됨
- OS의 주된 성능 향상은 더 좋은 자료구조와 알고리즘에 의한 것
- 고성능이 중요한 소량의 코드만 어셈블리 코드로 대체
- 장점
- Simple Structure (단층 구조)
- monolithic 구조 - 많은 기능들이 하나의 계층
- 많은 상용 운영체제, 잘 정의된 구조를 갖지 않음
- MS-DOS
- UNIX
- Layered Structure (계층 구조)
- 운영체제가 여러 계층으로 구분
- 각 계층은 하위 계층 위에 구축됨
- 장점 - 구현과 디버깅이 간단, 하위계층 연산이 어떻게 구현되어 있는지 알 필요 X, 무슨 동작만 하는지 알면 됨 ex) 네트워크 프로토콜, 웹 구현
- 단점 - 각 계층을 적절히 정의하는 것이 어렵고, 명확하지 않을 수 있음, 덜 효율적, 요즘 부정적
- Microkernel
- 필수적이 아닌 많은 부분을 사용자 공간으로 이동 → Small Kernel
- 개발 이유: UNIX 커널 확장되면서 관리 어려움
- 장점: 확장 용이, 운영체제 이식 용이, 높은 신뢰성과 보안성
- 단점: 시스템 함수 오버헤드로 인한 성능 저하
- 기본 기능
- 사용자 모듈과 사용자 공간에서 수행하는 서비스 간에 통신 기능 제공 → Message Passing 사용
- Modules
- kernel 구성
- a set of core components + loadable kernel modules
- loadable kernel module (LKM)
- 부팅 또는 실행시간 동안 동적으로 적재되어 커널 기능 확장
- 대부분 현대 운영체제에서 구현됨
- 모듈 인터페이스의 특징
- 각 core component가 분리됨
- 알려진 인터페이스를 통하여 다른 component/module과 통신
- layered 구조와 유사하지만 더 유연성 있음
- microkenel approach와 유사하지만 더 효율
- kernel 구성
- 장애 분석
- log file - 프로세스가 실패하면 오류 정보를 기록
- core dump - 오류 발생 프로세스의 메모리 저장
- crash dump - 커널 장애→커널 메모리 내용 저장
- 성능 조정도 디버깅 작업에 포함
- 병목 지점을 제거하여 시스템 성능 최적화 가능
- 추적
- dtrace
- strace
- Bootstarpping(booting)
- 커널을 적재하여 컴퓨터 시작하는 절차
- Bootstrap loader
- 커널을 찾아서 메모리에 적재하고 수행을 시작하는 일, ROM에 저장된 코드
- 시스템 진단 작업 수행, 전체 초기화 후 운영체제 시작시킴
- Firmware
- bootstarp 코드 변경 가능을 위해 ROM 대신 EPROM에 저장
- 하드웨어와 소프트웨어의 중간 특성
- RAM에서 실행하는 거보다 느려서 RAM에 복사하여 실행
- 보통 운영체제는 디스크에 저장하지만, 일부 시스템(smartphone, game console)은 EPROM/flash 저장
- 시스템 부트 과정
- 2.1 사용자를 위한 서비스
- 사용자 인터페이스
- 프로그램 실행
- 입출력 작업
- 파일 시스템 연산
- 통신
- 프로세스 간 정보를 교환
- 정보 교환 방법
- 공유 메모리(Shared Memory) 경유 - 동일 컴퓨터
- 메시지 전송(Meesage Passing) 경유 - 동일/다른 컴퓨터
- 오류 탐지
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 시스템 정지
- 오류 발생 프로세스 종료 - 오류코드 반환
- 오류 원인 제거 후 재실행
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 자원 할당
- 회계
- 보호와 보안
- 명령어 해석 - command line interface(CLI)
- command를 입력 받아서 수행
- 구현 방법
- 커널에 포함되어 구현, 또는 작업이 시작되거나, 로그온할 때에 대화형으로 수행되는 특수한 (시스템) 프로그램으로 구현
- 명령어 처리의 구현
- 내장 명령어
- 유틸리티 명령어
- 시스템 관리자, 파워 유저가 많이 사용 - 작업에 빨리 접근, 효울적
- 프로그램 기능이 있어서 반복적 작업에 효과적 → 셸 스크립트
- 그래픽 사용자 인터페이스 (GUI)
- 사용하기 쉬움
- 사용자 인터페이스는 대개 OS의 직접적인 기능이 아님
- 대게, 운영체제 시스템 구조에 포함되지 않음
- 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공
- 운영체제 프로그래밍 인터페이스
- 대개 C/C++와 같은 고급 언어 루틴 형태로 제공
- 프로그래머가 시스템 호출에 대한 C/C++ 함수를 호출하여 사용
- 서비스를 수행하는 저수준의 작업은 시스템호출 명령어를 포함하는 어셈블리 코드를 포함하여 작성됨
- MS-DOS는 시스템 호출 명령어를 사용하는 어셈블리언어 프로그램으로 운영체제 서비스를 요청하도록 되어있음
- 응용 프로그래밍 인터페이스 (API)
- 응용 프로그래머에서 사용 가능한 함수의 집합을 지정 (라이브러리 형태)
- 시스템 호출보다 API를 더 많이 사용하는 이유
- 프로그램 이식성
- 사용하기 쉬움
- 시스템 호출의 구현
- 각 시스템 호출에 번호가 부여됨
- 시스템 호출 인터페이스
- 매개 변수 전달 받음
- 관련된 시스템 호출을 호출
- status와 반환 값 반환
- 운영체제 인터페이스의 상세 내용은 API에 의해서 숨겨짐 → 사용자는 API 매개변수 규칙을 준수하고, 시스템 호출의 결과로 OS가 수행하는 작업에 대해서 이해하면 됨
- 시스템 호출 매개변수 전달
- 시스템 호출의 중요 범주
- 프로세스 제어
- 프로세스 생성/적재/실행/종료, 중지
- 속성 읽기/설정, 메모리 할당/반납
- 시간,사건 대기, 사건 알림
- 파일 관리
- 파일 생성, 삭제, 열기, 닫기 등
- 속성 읽기/설정
- 장치 관리
- 장치 요구, 반납, 읽기, 쓰기, 위치 변경
- 속성 읽기/설정, 논리적 부착/분리
- 정보 유지보수
- 통신
- 통신 연결 생성/삭제
- 메시지 송신, 수신, 상태 정보 전달
- 원격 장치 부착/분리
- 보호
- 네트워크와 인터넷 연결로 모든 컴퓨터 시스템에서 보호를 고려해야
- 프로세스 제어
- single-tasking 시스템: MS-DOS
- single-tasking 시스템: Arduino
- multi-tasking 시스템: UNIX/Linux
- 프로그램 개발과 실행을 위해 편리한 환경을 제공하는 프로그렘
- 설계 목표와 명세 정의
- 요구조건 지정 (설게 목표)
- 사용자 목표
- 시스템 목표
- 요구 조건은 애매하고 다양하게 해석될 수 있으며, 일반적으로 합의된 유일한 해법은 없음
- 운영체제의 설계 및 구현
- 모든 요구 조건을 해결하는 완전한 해결책은 없지만, 다양한 요구 조건에 대한 성공이 입증된 다양한 접근법은 있다.
- 소프트웨어 공학에서 개발된 일반적인 원칙 사용
- 내부 구조는 운영체제마다 다를 수 있음
- 기법(Mechanism)과 정책(Policy)
- 중요한 설계 원칙: 기법과 정책의 분리
- 기법: 어떻게 할 것인가? (How)
- 정책 변경에 민감하지 않는 일반적인 것이 바람직
- 정책: 무엇을 할 것인가? (What)
- 시간이 지남에 따라서 변경될 수 있음
- e.g. CPU 보호 방법
- 기법: CPU 보호를 위하여 타이머 구조 사용
- 정책: 특정 사용자를 위한 타이머 양 결정
- 기법과 정책의 분리는 flexibility를 위해서 중요
- 구현(Implementation)
- 운영체제의 구현
- 초기에는 어셈블리 언어로 작성
- 현재 대부분은 고급 언어로 작성
- system programs의 구현
- C, C++ 등 으로 작성됨
- 운영체제의 구현
- 고급 언어 구현의 장단점
- 장점
- 코드를 빠르게 작성
- 간결한 코드
- 이해와 디버깅이 쉬움
- 이식하기 훨씬 쉬움
- 단점이 문제가 안 되는 이유
- 컴파일러가 최적화 됨
- OS의 주된 성능 향상은 더 좋은 자료구조와 알고리즘에 의한 것
- 고성능이 중요한 소량의 코드만 어셈블리 코드로 대체
- 장점
- Simple Structure (단층 구조)
- monolithic 구조 - 많은 기능들이 하나의 계층
- 많은 상용 운영체제, 잘 정의된 구조를 갖지 않음
- MS-DOS
- UNIX
- Layered Structure (계층 구조)
- 운영체제가 여러 계층으로 구분
- 각 계층은 하위 계층 위에 구축됨
- 장점 - 구현과 디버깅이 간단, 하위계층 연산이 어떻게 구현되어 있는지 알 필요 X, 무슨 동작만 하는지 알면 됨 ex) 네트워크 프로토콜, 웹 구현
- 단점 - 각 계층을 적절히 정의하는 것이 어렵고, 명확하지 않을 수 있음, 덜 효율적, 요즘 부정적
- Microkernel
- 필수적이 아닌 많은 부분을 사용자 공간으로 이동 → Small Kernel
- 개발 이유: UNIX 커널 확장되면서 관리 어려움
- 장점: 확장 용이, 운영체제 이식 용이, 높은 신뢰성과 보안성
- 단점: 시스템 함수 오버헤드로 인한 성능 저하
- 기본 기능
- 사용자 모듈과 사용자 공간에서 수행하는 서비스 간에 통신 기능 제공 → Message Passing 사용
- Modules
- kernel 구성
- a set of core components + loadable kernel modules
- loadable kernel module (LKM)
- 부팅 또는 실행시간 동안 동적으로 적재되어 커널 기능 확장
- 대부분 현대 운영체제에서 구현됨
- 모듈 인터페이스의 특징
- 각 core component가 분리됨
- 알려진 인터페이스를 통하여 다른 component/module과 통신
- layered 구조와 유사하지만 더 유연성 있음
- microkenel approach와 유사하지만 더 효율
- kernel 구성
- 장애 분석
- log file - 프로세스가 실패하면 오류 정보를 기록
- core dump - 오류 발생 프로세스의 메모리 저장
- crash dump - 커널 장애→커널 메모리 내용 저장
- 성능 조정도 디버깅 작업에 포함
- 병목 지점을 제거하여 시스템 성능 최적화 가능
- 추적
- dtrace
- strace
- Bootstarpping(booting)
- 커널을 적재하여 컴퓨터 시작하는 절차
- Bootstrap loader
- 커널을 찾아서 메모리에 적재하고 수행을 시작하는 일, ROM에 저장된 코드
- 시스템 진단 작업 수행, 전체 초기화 후 운영체제 시작시킴
- Firmware
- bootstarp 코드 변경 가능을 위해 ROM 대신 EPROM에 저장
- 하드웨어와 소프트웨어의 중간 특성
- RAM에서 실행하는 거보다 느려서 RAM에 복사하여 실행
- 보통 운영체제는 디스크에 저장하지만, 일부 시스템(smartphone, game console)은 EPROM/flash 저장
- 시스템 부트 과정
- 2.1 사용자를 위한 서비스
- 사용자 인터페이스
- 프로그램 실행
- 입출력 작업
- 파일 시스템 연산
- 통신
- 프로세스 간 정보를 교환
- 정보 교환 방법
- 공유 메모리(Shared Memory) 경유 - 동일 컴퓨터
- 메시지 전송(Meesage Passing) 경유 - 동일/다른 컴퓨터
- 오류 탐지
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 시스템 정지
- 오류 발생 프로세스 종료 - 오류코드 반환
- 오류 원인 제거 후 재실행
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 자원 할당
- 회계
- 보호와 보안
- 명령어 해석 - command line interface(CLI)
- command를 입력 받아서 수행
- 구현 방법
- 커널에 포함되어 구현, 또는 작업이 시작되거나, 로그온할 때에 대화형으로 수행되는 특수한 (시스템) 프로그램으로 구현
- 명령어 처리의 구현
- 내장 명령어
- 유틸리티 명령어
- 시스템 관리자, 파워 유저가 많이 사용 - 작업에 빨리 접근, 효울적
- 프로그램 기능이 있어서 반복적 작업에 효과적 → 셸 스크립트
- 그래픽 사용자 인터페이스 (GUI)
- 사용하기 쉬움
- 사용자 인터페이스는 대개 OS의 직접적인 기능이 아님
- 대게, 운영체제 시스템 구조에 포함되지 않음
- 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공
- 운영체제 프로그래밍 인터페이스
- 대개 C/C++와 같은 고급 언어 루틴 형태로 제공
- 프로그래머가 시스템 호출에 대한 C/C++ 함수를 호출하여 사용
- 서비스를 수행하는 저수준의 작업은 시스템호출 명령어를 포함하는 어셈블리 코드를 포함하여 작성됨
- MS-DOS는 시스템 호출 명령어를 사용하는 어셈블리언어 프로그램으로 운영체제 서비스를 요청하도록 되어있음
- 응용 프로그래밍 인터페이스 (API)
- 응용 프로그래머에서 사용 가능한 함수의 집합을 지정 (라이브러리 형태)
- 시스템 호출보다 API를 더 많이 사용하는 이유
- 프로그램 이식성
- 사용하기 쉬움
- 시스템 호출의 구현
- 각 시스템 호출에 번호가 부여됨
- 시스템 호출 인터페이스
- 매개 변수 전달 받음
- 관련된 시스템 호출을 호출
- status와 반환 값 반환
- 운영체제 인터페이스의 상세 내용은 API에 의해서 숨겨짐 → 사용자는 API 매개변수 규칙을 준수하고, 시스템 호출의 결과로 OS가 수행하는 작업에 대해서 이해하면 됨
- 시스템 호출 매개변수 전달
- 시스템 호출의 중요 범주
- 프로세스 제어
- 프로세스 생성/적재/실행/종료, 중지
- 속성 읽기/설정, 메모리 할당/반납
- 시간,사건 대기, 사건 알림
- 파일 관리
- 파일 생성, 삭제, 열기, 닫기 등
- 속성 읽기/설정
- 장치 관리
- 장치 요구, 반납, 읽기, 쓰기, 위치 변경
- 속성 읽기/설정, 논리적 부착/분리
- 정보 유지보수
- 통신
- 통신 연결 생성/삭제
- 메시지 송신, 수신, 상태 정보 전달
- 원격 장치 부착/분리
- 보호
- 네트워크와 인터넷 연결로 모든 컴퓨터 시스템에서 보호를 고려해야
- 프로세스 제어
- single-tasking 시스템: MS-DOS
- single-tasking 시스템: Arduino
- multi-tasking 시스템: UNIX/Linux
- 프로그램 개발과 실행을 위해 편리한 환경을 제공하는 프로그렘
- 설계 목표와 명세 정의
- 요구조건 지정 (설게 목표)
- 사용자 목표
- 시스템 목표
- 요구 조건은 애매하고 다양하게 해석될 수 있으며, 일반적으로 합의된 유일한 해법은 없음
- 운영체제의 설계 및 구현
- 모든 요구 조건을 해결하는 완전한 해결책은 없지만, 다양한 요구 조건에 대한 성공이 입증된 다양한 접근법은 있다.
- 소프트웨어 공학에서 개발된 일반적인 원칙 사용
- 내부 구조는 운영체제마다 다를 수 있음
- 기법(Mechanism)과 정책(Policy)
- 중요한 설계 원칙: 기법과 정책의 분리
- 기법: 어떻게 할 것인가? (How)
- 정책 변경에 민감하지 않는 일반적인 것이 바람직
- 정책: 무엇을 할 것인가? (What)
- 시간이 지남에 따라서 변경될 수 있음
- e.g. CPU 보호 방법
- 기법: CPU 보호를 위하여 타이머 구조 사용
- 정책: 특정 사용자를 위한 타이머 양 결정
- 기법과 정책의 분리는 flexibility를 위해서 중요
- 구현(Implementation)
- 운영체제의 구현
- 초기에는 어셈블리 언어로 작성
- 현재 대부분은 고급 언어로 작성
- system programs의 구현
- C, C++ 등 으로 작성됨
- 운영체제의 구현
- 고급 언어 구현의 장단점
- 장점
- 코드를 빠르게 작성
- 간결한 코드
- 이해와 디버깅이 쉬움
- 이식하기 훨씬 쉬움
- 단점이 문제가 안 되는 이유
- 컴파일러가 최적화 됨
- OS의 주된 성능 향상은 더 좋은 자료구조와 알고리즘에 의한 것
- 고성능이 중요한 소량의 코드만 어셈블리 코드로 대체
- 장점
- Simple Structure (단층 구조)
- monolithic 구조 - 많은 기능들이 하나의 계층
- 많은 상용 운영체제, 잘 정의된 구조를 갖지 않음
- MS-DOS
- UNIX
- Layered Structure (계층 구조)
- 운영체제가 여러 계층으로 구분
- 각 계층은 하위 계층 위에 구축됨
- 장점 - 구현과 디버깅이 간단, 하위계층 연산이 어떻게 구현되어 있는지 알 필요 X, 무슨 동작만 하는지 알면 됨 ex) 네트워크 프로토콜, 웹 구현
- 단점 - 각 계층을 적절히 정의하는 것이 어렵고, 명확하지 않을 수 있음, 덜 효율적, 요즘 부정적
- Microkernel
- 필수적이 아닌 많은 부분을 사용자 공간으로 이동 → Small Kernel
- 개발 이유: UNIX 커널 확장되면서 관리 어려움
- 장점: 확장 용이, 운영체제 이식 용이, 높은 신뢰성과 보안성
- 단점: 시스템 함수 오버헤드로 인한 성능 저하
- 기본 기능
- 사용자 모듈과 사용자 공간에서 수행하는 서비스 간에 통신 기능 제공 → Message Passing 사용
- Modules
- kernel 구성
- a set of core components + loadable kernel modules
- loadable kernel module (LKM)
- 부팅 또는 실행시간 동안 동적으로 적재되어 커널 기능 확장
- 대부분 현대 운영체제에서 구현됨
- 모듈 인터페이스의 특징
- 각 core component가 분리됨
- 알려진 인터페이스를 통하여 다른 component/module과 통신
- layered 구조와 유사하지만 더 유연성 있음
- microkenel approach와 유사하지만 더 효율
- kernel 구성
- 장애 분석
- log file - 프로세스가 실패하면 오류 정보를 기록
- core dump - 오류 발생 프로세스의 메모리 저장
- crash dump - 커널 장애→커널 메모리 내용 저장
- 성능 조정도 디버깅 작업에 포함
- 병목 지점을 제거하여 시스템 성능 최적화 가능
- 추적
- dtrace
- strace
- Bootstarpping(booting)
- 커널을 적재하여 컴퓨터 시작하는 절차
- Bootstrap loader
- 커널을 찾아서 메모리에 적재하고 수행을 시작하는 일, ROM에 저장된 코드
- 시스템 진단 작업 수행, 전체 초기화 후 운영체제 시작시킴
- Firmware
- bootstarp 코드 변경 가능을 위해 ROM 대신 EPROM에 저장
- 하드웨어와 소프트웨어의 중간 특성
- RAM에서 실행하는 거보다 느려서 RAM에 복사하여 실행
- 보통 운영체제는 디스크에 저장하지만, 일부 시스템(smartphone, game console)은 EPROM/flash 저장
- 시스템 부트 과정
- 2.1 사용자를 위한 서비스
- 사용자 인터페이스
- 프로그램 실행
- 입출력 작업
- 파일 시스템 연산
- 통신
- 프로세스 간 정보를 교환
- 정보 교환 방법
- 공유 메모리(Shared Memory) 경유 - 동일 컴퓨터
- 메시지 전송(Meesage Passing) 경유 - 동일/다른 컴퓨터
- 오류 탐지
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 시스템 정지
- 오류 발생 프로세스 종료 - 오류코드 반환
- 오류 원인 제거 후 재실행
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 자원 할당
- 회계
- 보호와 보안
- 명령어 해석 - command line interface(CLI)
- command를 입력 받아서 수행
- 구현 방법
- 커널에 포함되어 구현, 또는 작업이 시작되거나, 로그온할 때에 대화형으로 수행되는 특수한 (시스템) 프로그램으로 구현
- 명령어 처리의 구현
- 내장 명령어
- 유틸리티 명령어
- 시스템 관리자, 파워 유저가 많이 사용 - 작업에 빨리 접근, 효울적
- 프로그램 기능이 있어서 반복적 작업에 효과적 → 셸 스크립트
- 그래픽 사용자 인터페이스 (GUI)
- 사용하기 쉬움
- 사용자 인터페이스는 대개 OS의 직접적인 기능이 아님
- 대게, 운영체제 시스템 구조에 포함되지 않음
- 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공
- 운영체제 프로그래밍 인터페이스
- 대개 C/C++와 같은 고급 언어 루틴 형태로 제공
- 프로그래머가 시스템 호출에 대한 C/C++ 함수를 호출하여 사용
- 서비스를 수행하는 저수준의 작업은 시스템호출 명령어를 포함하는 어셈블리 코드를 포함하여 작성됨
- MS-DOS는 시스템 호출 명령어를 사용하는 어셈블리언어 프로그램으로 운영체제 서비스를 요청하도록 되어있음
- 응용 프로그래밍 인터페이스 (API)
- 응용 프로그래머에서 사용 가능한 함수의 집합을 지정 (라이브러리 형태)
- 시스템 호출보다 API를 더 많이 사용하는 이유
- 프로그램 이식성
- 사용하기 쉬움
- 시스템 호출의 구현
- 각 시스템 호출에 번호가 부여됨
- 시스템 호출 인터페이스
- 매개 변수 전달 받음
- 관련된 시스템 호출을 호출
- status와 반환 값 반환
- 운영체제 인터페이스의 상세 내용은 API에 의해서 숨겨짐 → 사용자는 API 매개변수 규칙을 준수하고, 시스템 호출의 결과로 OS가 수행하는 작업에 대해서 이해하면 됨
- 시스템 호출 매개변수 전달
- 시스템 호출의 중요 범주
- 프로세스 제어
- 프로세스 생성/적재/실행/종료, 중지
- 속성 읽기/설정, 메모리 할당/반납
- 시간,사건 대기, 사건 알림
- 파일 관리
- 파일 생성, 삭제, 열기, 닫기 등
- 속성 읽기/설정
- 장치 관리
- 장치 요구, 반납, 읽기, 쓰기, 위치 변경
- 속성 읽기/설정, 논리적 부착/분리
- 정보 유지보수
- 통신
- 통신 연결 생성/삭제
- 메시지 송신, 수신, 상태 정보 전달
- 원격 장치 부착/분리
- 보호
- 네트워크와 인터넷 연결로 모든 컴퓨터 시스템에서 보호를 고려해야
- 프로세스 제어
- single-tasking 시스템: MS-DOS
- single-tasking 시스템: Arduino
- multi-tasking 시스템: UNIX/Linux
- 프로그램 개발과 실행을 위해 편리한 환경을 제공하는 프로그렘
- 설계 목표와 명세 정의
- 요구조건 지정 (설게 목표)
- 사용자 목표
- 시스템 목표
- 요구 조건은 애매하고 다양하게 해석될 수 있으며, 일반적으로 합의된 유일한 해법은 없음
- 운영체제의 설계 및 구현
- 모든 요구 조건을 해결하는 완전한 해결책은 없지만, 다양한 요구 조건에 대한 성공이 입증된 다양한 접근법은 있다.
- 소프트웨어 공학에서 개발된 일반적인 원칙 사용
- 내부 구조는 운영체제마다 다를 수 있음
- 기법(Mechanism)과 정책(Policy)
- 중요한 설계 원칙: 기법과 정책의 분리
- 기법: 어떻게 할 것인가? (How)
- 정책 변경에 민감하지 않는 일반적인 것이 바람직
- 정책: 무엇을 할 것인가? (What)
- 시간이 지남에 따라서 변경될 수 있음
- e.g. CPU 보호 방법
- 기법: CPU 보호를 위하여 타이머 구조 사용
- 정책: 특정 사용자를 위한 타이머 양 결정
- 기법과 정책의 분리는 flexibility를 위해서 중요
- 구현(Implementation)
- 운영체제의 구현
- 초기에는 어셈블리 언어로 작성
- 현재 대부분은 고급 언어로 작성
- system programs의 구현
- C, C++ 등 으로 작성됨
- 운영체제의 구현
- 고급 언어 구현의 장단점
- 장점
- 코드를 빠르게 작성
- 간결한 코드
- 이해와 디버깅이 쉬움
- 이식하기 훨씬 쉬움
- 단점이 문제가 안 되는 이유
- 컴파일러가 최적화 됨
- OS의 주된 성능 향상은 더 좋은 자료구조와 알고리즘에 의한 것
- 고성능이 중요한 소량의 코드만 어셈블리 코드로 대체
- 장점
- Simple Structure (단층 구조)
- monolithic 구조 - 많은 기능들이 하나의 계층
- 많은 상용 운영체제, 잘 정의된 구조를 갖지 않음
- MS-DOS
- UNIX
- Layered Structure (계층 구조)
- 운영체제가 여러 계층으로 구분
- 각 계층은 하위 계층 위에 구축됨
- 장점 - 구현과 디버깅이 간단, 하위계층 연산이 어떻게 구현되어 있는지 알 필요 X, 무슨 동작만 하는지 알면 됨 ex) 네트워크 프로토콜, 웹 구현
- 단점 - 각 계층을 적절히 정의하는 것이 어렵고, 명확하지 않을 수 있음, 덜 효율적, 요즘 부정적
- Microkernel
- 필수적이 아닌 많은 부분을 사용자 공간으로 이동 → Small Kernel
- 개발 이유: UNIX 커널 확장되면서 관리 어려움
- 장점: 확장 용이, 운영체제 이식 용이, 높은 신뢰성과 보안성
- 단점: 시스템 함수 오버헤드로 인한 성능 저하
- 기본 기능
- 사용자 모듈과 사용자 공간에서 수행하는 서비스 간에 통신 기능 제공 → Message Passing 사용
- Modules
- kernel 구성
- a set of core components + loadable kernel modules
- loadable kernel module (LKM)
- 부팅 또는 실행시간 동안 동적으로 적재되어 커널 기능 확장
- 대부분 현대 운영체제에서 구현됨
- 모듈 인터페이스의 특징
- 각 core component가 분리됨
- 알려진 인터페이스를 통하여 다른 component/module과 통신
- layered 구조와 유사하지만 더 유연성 있음
- microkenel approach와 유사하지만 더 효율
- kernel 구성
- 장애 분석
- log file - 프로세스가 실패하면 오류 정보를 기록
- core dump - 오류 발생 프로세스의 메모리 저장
- crash dump - 커널 장애→커널 메모리 내용 저장
- 성능 조정도 디버깅 작업에 포함
- 병목 지점을 제거하여 시스템 성능 최적화 가능
- 추적
- dtrace
- strace
- Bootstarpping(booting)
- 커널을 적재하여 컴퓨터 시작하는 절차
- Bootstrap loader
- 커널을 찾아서 메모리에 적재하고 수행을 시작하는 일, ROM에 저장된 코드
- 시스템 진단 작업 수행, 전체 초기화 후 운영체제 시작시킴
- Firmware
- bootstarp 코드 변경 가능을 위해 ROM 대신 EPROM에 저장
- 하드웨어와 소프트웨어의 중간 특성
- RAM에서 실행하는 거보다 느려서 RAM에 복사하여 실행
- 보통 운영체제는 디스크에 저장하지만, 일부 시스템(smartphone, game console)은 EPROM/flash 저장
- 시스템 부트 과정
- 2.1 사용자를 위한 서비스
- 사용자 인터페이스
- 프로그램 실행
- 입출력 작업
- 파일 시스템 연산
- 통신
- 프로세스 간 정보를 교환
- 정보 교환 방법
- 공유 메모리(Shared Memory) 경유 - 동일 컴퓨터
- 메시지 전송(Meesage Passing) 경유 - 동일/다른 컴퓨터
- 오류 탐지
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 시스템 정지
- 오류 발생 프로세스 종료 - 오류코드 반환
- 오류 원인 제거 후 재실행
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 자원 할당
- 회계
- 보호와 보안
- 명령어 해석 - command line interface(CLI)
- command를 입력 받아서 수행
- 구현 방법
- 커널에 포함되어 구현, 또는 작업이 시작되거나, 로그온할 때에 대화형으로 수행되는 특수한 (시스템) 프로그램으로 구현
- 명령어 처리의 구현
- 내장 명령어
- 유틸리티 명령어
- 시스템 관리자, 파워 유저가 많이 사용 - 작업에 빨리 접근, 효울적
- 프로그램 기능이 있어서 반복적 작업에 효과적 → 셸 스크립트
- 그래픽 사용자 인터페이스 (GUI)
- 사용하기 쉬움
- 사용자 인터페이스는 대개 OS의 직접적인 기능이 아님
- 대게, 운영체제 시스템 구조에 포함되지 않음
- 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공
- 운영체제 프로그래밍 인터페이스
- 대개 C/C++와 같은 고급 언어 루틴 형태로 제공
- 프로그래머가 시스템 호출에 대한 C/C++ 함수를 호출하여 사용
- 서비스를 수행하는 저수준의 작업은 시스템호출 명령어를 포함하는 어셈블리 코드를 포함하여 작성됨
- MS-DOS는 시스템 호출 명령어를 사용하는 어셈블리언어 프로그램으로 운영체제 서비스를 요청하도록 되어있음
- 응용 프로그래밍 인터페이스 (API)
- 응용 프로그래머에서 사용 가능한 함수의 집합을 지정 (라이브러리 형태)
- 시스템 호출보다 API를 더 많이 사용하는 이유
- 프로그램 이식성
- 사용하기 쉬움
- 시스템 호출의 구현
- 각 시스템 호출에 번호가 부여됨
- 시스템 호출 인터페이스
- 매개 변수 전달 받음
- 관련된 시스템 호출을 호출
- status와 반환 값 반환
- 운영체제 인터페이스의 상세 내용은 API에 의해서 숨겨짐 → 사용자는 API 매개변수 규칙을 준수하고, 시스템 호출의 결과로 OS가 수행하는 작업에 대해서 이해하면 됨
- 시스템 호출 매개변수 전달
- 시스템 호출의 중요 범주
- 프로세스 제어
- 프로세스 생성/적재/실행/종료, 중지
- 속성 읽기/설정, 메모리 할당/반납
- 시간,사건 대기, 사건 알림
- 파일 관리
- 파일 생성, 삭제, 열기, 닫기 등
- 속성 읽기/설정
- 장치 관리
- 장치 요구, 반납, 읽기, 쓰기, 위치 변경
- 속성 읽기/설정, 논리적 부착/분리
- 정보 유지보수
- 통신
- 통신 연결 생성/삭제
- 메시지 송신, 수신, 상태 정보 전달
- 원격 장치 부착/분리
- 보호
- 네트워크와 인터넷 연결로 모든 컴퓨터 시스템에서 보호를 고려해야
- 프로세스 제어
- single-tasking 시스템: MS-DOS
- single-tasking 시스템: Arduino
- multi-tasking 시스템: UNIX/Linux
- 프로그램 개발과 실행을 위해 편리한 환경을 제공하는 프로그렘
- 설계 목표와 명세 정의
- 요구조건 지정 (설게 목표)
- 사용자 목표
- 시스템 목표
- 요구 조건은 애매하고 다양하게 해석될 수 있으며, 일반적으로 합의된 유일한 해법은 없음
- 운영체제의 설계 및 구현
- 모든 요구 조건을 해결하는 완전한 해결책은 없지만, 다양한 요구 조건에 대한 성공이 입증된 다양한 접근법은 있다.
- 소프트웨어 공학에서 개발된 일반적인 원칙 사용
- 내부 구조는 운영체제마다 다를 수 있음
- 기법(Mechanism)과 정책(Policy)
- 중요한 설계 원칙: 기법과 정책의 분리
- 기법: 어떻게 할 것인가? (How)
- 정책 변경에 민감하지 않는 일반적인 것이 바람직
- 정책: 무엇을 할 것인가? (What)
- 시간이 지남에 따라서 변경될 수 있음
- e.g. CPU 보호 방법
- 기법: CPU 보호를 위하여 타이머 구조 사용
- 정책: 특정 사용자를 위한 타이머 양 결정
- 기법과 정책의 분리는 flexibility를 위해서 중요
- 구현(Implementation)
- 운영체제의 구현
- 초기에는 어셈블리 언어로 작성
- 현재 대부분은 고급 언어로 작성
- system programs의 구현
- C, C++ 등 으로 작성됨
- 운영체제의 구현
- 고급 언어 구현의 장단점
- 장점
- 코드를 빠르게 작성
- 간결한 코드
- 이해와 디버깅이 쉬움
- 이식하기 훨씬 쉬움
- 단점이 문제가 안 되는 이유
- 컴파일러가 최적화 됨
- OS의 주된 성능 향상은 더 좋은 자료구조와 알고리즘에 의한 것
- 고성능이 중요한 소량의 코드만 어셈블리 코드로 대체
- 장점
- Simple Structure (단층 구조)
- monolithic 구조 - 많은 기능들이 하나의 계층
- 많은 상용 운영체제, 잘 정의된 구조를 갖지 않음
- MS-DOS
- UNIX
- Layered Structure (계층 구조)
- 운영체제가 여러 계층으로 구분
- 각 계층은 하위 계층 위에 구축됨
- 장점 - 구현과 디버깅이 간단, 하위계층 연산이 어떻게 구현되어 있는지 알 필요 X, 무슨 동작만 하는지 알면 됨 ex) 네트워크 프로토콜, 웹 구현
- 단점 - 각 계층을 적절히 정의하는 것이 어렵고, 명확하지 않을 수 있음, 덜 효율적, 요즘 부정적
- Microkernel
- 필수적이 아닌 많은 부분을 사용자 공간으로 이동 → Small Kernel
- 개발 이유: UNIX 커널 확장되면서 관리 어려움
- 장점: 확장 용이, 운영체제 이식 용이, 높은 신뢰성과 보안성
- 단점: 시스템 함수 오버헤드로 인한 성능 저하
- 기본 기능
- 사용자 모듈과 사용자 공간에서 수행하는 서비스 간에 통신 기능 제공 → Message Passing 사용
- Modules
- kernel 구성
- a set of core components + loadable kernel modules
- loadable kernel module (LKM)
- 부팅 또는 실행시간 동안 동적으로 적재되어 커널 기능 확장
- 대부분 현대 운영체제에서 구현됨
- 모듈 인터페이스의 특징
- 각 core component가 분리됨
- 알려진 인터페이스를 통하여 다른 component/module과 통신
- layered 구조와 유사하지만 더 유연성 있음
- microkenel approach와 유사하지만 더 효율
- kernel 구성
- 장애 분석
- log file - 프로세스가 실패하면 오류 정보를 기록
- core dump - 오류 발생 프로세스의 메모리 저장
- crash dump - 커널 장애→커널 메모리 내용 저장
- 성능 조정도 디버깅 작업에 포함
- 병목 지점을 제거하여 시스템 성능 최적화 가능
- 추적
- dtrace
- strace
- Bootstarpping(booting)
- 커널을 적재하여 컴퓨터 시작하는 절차
- Bootstrap loader
- 커널을 찾아서 메모리에 적재하고 수행을 시작하는 일, ROM에 저장된 코드
- 시스템 진단 작업 수행, 전체 초기화 후 운영체제 시작시킴
- Firmware
- bootstarp 코드 변경 가능을 위해 ROM 대신 EPROM에 저장
- 하드웨어와 소프트웨어의 중간 특성
- RAM에서 실행하는 거보다 느려서 RAM에 복사하여 실행
- 보통 운영체제는 디스크에 저장하지만, 일부 시스템(smartphone, game console)은 EPROM/flash 저장
- 시스템 부트 과정
- 2.1 사용자를 위한 서비스
- 사용자 인터페이스
- 프로그램 실행
- 입출력 작업
- 파일 시스템 연산
- 통신
- 프로세스 간 정보를 교환
- 정보 교환 방법
- 공유 메모리(Shared Memory) 경유 - 동일 컴퓨터
- 메시지 전송(Meesage Passing) 경유 - 동일/다른 컴퓨터
- 오류 탐지
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 시스템 정지
- 오류 발생 프로세스 종료 - 오류코드 반환
- 오류 원인 제거 후 재실행
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 자원 할당
- 회계
- 보호와 보안
- 명령어 해석 - command line interface(CLI)
- command를 입력 받아서 수행
- 구현 방법
- 커널에 포함되어 구현, 또는 작업이 시작되거나, 로그온할 때에 대화형으로 수행되는 특수한 (시스템) 프로그램으로 구현
- 명령어 처리의 구현
- 내장 명령어
- 유틸리티 명령어
- 시스템 관리자, 파워 유저가 많이 사용 - 작업에 빨리 접근, 효울적
- 프로그램 기능이 있어서 반복적 작업에 효과적 → 셸 스크립트
- 그래픽 사용자 인터페이스 (GUI)
- 사용하기 쉬움
- 사용자 인터페이스는 대개 OS의 직접적인 기능이 아님
- 대게, 운영체제 시스템 구조에 포함되지 않음
- 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공
- 운영체제 프로그래밍 인터페이스
- 대개 C/C++와 같은 고급 언어 루틴 형태로 제공
- 프로그래머가 시스템 호출에 대한 C/C++ 함수를 호출하여 사용
- 서비스를 수행하는 저수준의 작업은 시스템호출 명령어를 포함하는 어셈블리 코드를 포함하여 작성됨
- MS-DOS는 시스템 호출 명령어를 사용하는 어셈블리언어 프로그램으로 운영체제 서비스를 요청하도록 되어있음
- 응용 프로그래밍 인터페이스 (API)
- 응용 프로그래머에서 사용 가능한 함수의 집합을 지정 (라이브러리 형태)
- 시스템 호출보다 API를 더 많이 사용하는 이유
- 프로그램 이식성
- 사용하기 쉬움
- 시스템 호출의 구현
- 각 시스템 호출에 번호가 부여됨
- 시스템 호출 인터페이스
- 매개 변수 전달 받음
- 관련된 시스템 호출을 호출
- status와 반환 값 반환
- 운영체제 인터페이스의 상세 내용은 API에 의해서 숨겨짐 → 사용자는 API 매개변수 규칙을 준수하고, 시스템 호출의 결과로 OS가 수행하는 작업에 대해서 이해하면 됨
- 시스템 호출 매개변수 전달
- 시스템 호출의 중요 범주
- 프로세스 제어
- 프로세스 생성/적재/실행/종료, 중지
- 속성 읽기/설정, 메모리 할당/반납
- 시간,사건 대기, 사건 알림
- 파일 관리
- 파일 생성, 삭제, 열기, 닫기 등
- 속성 읽기/설정
- 장치 관리
- 장치 요구, 반납, 읽기, 쓰기, 위치 변경
- 속성 읽기/설정, 논리적 부착/분리
- 정보 유지보수
- 통신
- 통신 연결 생성/삭제
- 메시지 송신, 수신, 상태 정보 전달
- 원격 장치 부착/분리
- 보호
- 네트워크와 인터넷 연결로 모든 컴퓨터 시스템에서 보호를 고려해야
- 프로세스 제어
- single-tasking 시스템: MS-DOS
- single-tasking 시스템: Arduino
- multi-tasking 시스템: UNIX/Linux
- 프로그램 개발과 실행을 위해 편리한 환경을 제공하는 프로그렘
- 설계 목표와 명세 정의
- 요구조건 지정 (설게 목표)
- 사용자 목표
- 시스템 목표
- 요구 조건은 애매하고 다양하게 해석될 수 있으며, 일반적으로 합의된 유일한 해법은 없음
- 운영체제의 설계 및 구현
- 모든 요구 조건을 해결하는 완전한 해결책은 없지만, 다양한 요구 조건에 대한 성공이 입증된 다양한 접근법은 있다.
- 소프트웨어 공학에서 개발된 일반적인 원칙 사용
- 내부 구조는 운영체제마다 다를 수 있음
- 기법(Mechanism)과 정책(Policy)
- 중요한 설계 원칙: 기법과 정책의 분리
- 기법: 어떻게 할 것인가? (How)
- 정책 변경에 민감하지 않는 일반적인 것이 바람직
- 정책: 무엇을 할 것인가? (What)
- 시간이 지남에 따라서 변경될 수 있음
- e.g. CPU 보호 방법
- 기법: CPU 보호를 위하여 타이머 구조 사용
- 정책: 특정 사용자를 위한 타이머 양 결정
- 기법과 정책의 분리는 flexibility를 위해서 중요
- 구현(Implementation)
- 운영체제의 구현
- 초기에는 어셈블리 언어로 작성
- 현재 대부분은 고급 언어로 작성
- system programs의 구현
- C, C++ 등 으로 작성됨
- 운영체제의 구현
- 고급 언어 구현의 장단점
- 장점
- 코드를 빠르게 작성
- 간결한 코드
- 이해와 디버깅이 쉬움
- 이식하기 훨씬 쉬움
- 단점이 문제가 안 되는 이유
- 컴파일러가 최적화 됨
- OS의 주된 성능 향상은 더 좋은 자료구조와 알고리즘에 의한 것
- 고성능이 중요한 소량의 코드만 어셈블리 코드로 대체
- 장점
- Simple Structure (단층 구조)
- monolithic 구조 - 많은 기능들이 하나의 계층
- 많은 상용 운영체제, 잘 정의된 구조를 갖지 않음
- MS-DOS
- UNIX
- Layered Structure (계층 구조)
- 운영체제가 여러 계층으로 구분
- 각 계층은 하위 계층 위에 구축됨
- 장점 - 구현과 디버깅이 간단, 하위계층 연산이 어떻게 구현되어 있는지 알 필요 X, 무슨 동작만 하는지 알면 됨 ex) 네트워크 프로토콜, 웹 구현
- 단점 - 각 계층을 적절히 정의하는 것이 어렵고, 명확하지 않을 수 있음, 덜 효율적, 요즘 부정적
- Microkernel
- 필수적이 아닌 많은 부분을 사용자 공간으로 이동 → Small Kernel
- 개발 이유: UNIX 커널 확장되면서 관리 어려움
- 장점: 확장 용이, 운영체제 이식 용이, 높은 신뢰성과 보안성
- 단점: 시스템 함수 오버헤드로 인한 성능 저하
- 기본 기능
- 사용자 모듈과 사용자 공간에서 수행하는 서비스 간에 통신 기능 제공 → Message Passing 사용
- Modules
- kernel 구성
- a set of core components + loadable kernel modules
- loadable kernel module (LKM)
- 부팅 또는 실행시간 동안 동적으로 적재되어 커널 기능 확장
- 대부분 현대 운영체제에서 구현됨
- 모듈 인터페이스의 특징
- 각 core component가 분리됨
- 알려진 인터페이스를 통하여 다른 component/module과 통신
- layered 구조와 유사하지만 더 유연성 있음
- microkenel approach와 유사하지만 더 효율
- kernel 구성
- 장애 분석
- log file - 프로세스가 실패하면 오류 정보를 기록
- core dump - 오류 발생 프로세스의 메모리 저장
- crash dump - 커널 장애→커널 메모리 내용 저장
- 성능 조정도 디버깅 작업에 포함
- 병목 지점을 제거하여 시스템 성능 최적화 가능
- 추적
- dtrace
- strace
- Bootstarpping(booting)
- 커널을 적재하여 컴퓨터 시작하는 절차
- Bootstrap loader
- 커널을 찾아서 메모리에 적재하고 수행을 시작하는 일, ROM에 저장된 코드
- 시스템 진단 작업 수행, 전체 초기화 후 운영체제 시작시킴
- Firmware
- bootstarp 코드 변경 가능을 위해 ROM 대신 EPROM에 저장
- 하드웨어와 소프트웨어의 중간 특성
- RAM에서 실행하는 거보다 느려서 RAM에 복사하여 실행
- 보통 운영체제는 디스크에 저장하지만, 일부 시스템(smartphone, game console)은 EPROM/flash 저장
- 시스템 부트 과정
- 2.1 사용자를 위한 서비스
- 사용자 인터페이스
- 프로그램 실행
- 입출력 작업
- 파일 시스템 연산
- 통신
- 프로세스 간 정보를 교환
- 정보 교환 방법
- 공유 메모리(Shared Memory) 경유 - 동일 컴퓨터
- 메시지 전송(Meesage Passing) 경유 - 동일/다른 컴퓨터
- 오류 탐지
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 시스템 정지
- 오류 발생 프로세스 종료 - 오류코드 반환
- 오류 원인 제거 후 재실행
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 자원 할당
- 회계
- 보호와 보안
- 명령어 해석 - command line interface(CLI)
- command를 입력 받아서 수행
- 구현 방법
- 커널에 포함되어 구현, 또는 작업이 시작되거나, 로그온할 때에 대화형으로 수행되는 특수한 (시스템) 프로그램으로 구현
- 명령어 처리의 구현
- 내장 명령어
- 유틸리티 명령어
- 시스템 관리자, 파워 유저가 많이 사용 - 작업에 빨리 접근, 효울적
- 프로그램 기능이 있어서 반복적 작업에 효과적 → 셸 스크립트
- 그래픽 사용자 인터페이스 (GUI)
- 사용하기 쉬움
- 사용자 인터페이스는 대개 OS의 직접적인 기능이 아님
- 대게, 운영체제 시스템 구조에 포함되지 않음
- 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공
- 운영체제 프로그래밍 인터페이스
- 대개 C/C++와 같은 고급 언어 루틴 형태로 제공
- 프로그래머가 시스템 호출에 대한 C/C++ 함수를 호출하여 사용
- 서비스를 수행하는 저수준의 작업은 시스템호출 명령어를 포함하는 어셈블리 코드를 포함하여 작성됨
- MS-DOS는 시스템 호출 명령어를 사용하는 어셈블리언어 프로그램으로 운영체제 서비스를 요청하도록 되어있음
- 응용 프로그래밍 인터페이스 (API)
- 응용 프로그래머에서 사용 가능한 함수의 집합을 지정 (라이브러리 형태)
- 시스템 호출보다 API를 더 많이 사용하는 이유
- 프로그램 이식성
- 사용하기 쉬움
- 시스템 호출의 구현
- 각 시스템 호출에 번호가 부여됨
- 시스템 호출 인터페이스
- 매개 변수 전달 받음
- 관련된 시스템 호출을 호출
- status와 반환 값 반환
- 운영체제 인터페이스의 상세 내용은 API에 의해서 숨겨짐 → 사용자는 API 매개변수 규칙을 준수하고, 시스템 호출의 결과로 OS가 수행하는 작업에 대해서 이해하면 됨
- 시스템 호출 매개변수 전달
- 시스템 호출의 중요 범주
- 프로세스 제어
- 프로세스 생성/적재/실행/종료, 중지
- 속성 읽기/설정, 메모리 할당/반납
- 시간,사건 대기, 사건 알림
- 파일 관리
- 파일 생성, 삭제, 열기, 닫기 등
- 속성 읽기/설정
- 장치 관리
- 장치 요구, 반납, 읽기, 쓰기, 위치 변경
- 속성 읽기/설정, 논리적 부착/분리
- 정보 유지보수
- 통신
- 통신 연결 생성/삭제
- 메시지 송신, 수신, 상태 정보 전달
- 원격 장치 부착/분리
- 보호
- 네트워크와 인터넷 연결로 모든 컴퓨터 시스템에서 보호를 고려해야
- 프로세스 제어
- single-tasking 시스템: MS-DOS
- single-tasking 시스템: Arduino
- multi-tasking 시스템: UNIX/Linux
- 프로그램 개발과 실행을 위해 편리한 환경을 제공하는 프로그렘
- 설계 목표와 명세 정의
- 요구조건 지정 (설게 목표)
- 사용자 목표
- 시스템 목표
- 요구 조건은 애매하고 다양하게 해석될 수 있으며, 일반적으로 합의된 유일한 해법은 없음
- 운영체제의 설계 및 구현
- 모든 요구 조건을 해결하는 완전한 해결책은 없지만, 다양한 요구 조건에 대한 성공이 입증된 다양한 접근법은 있다.
- 소프트웨어 공학에서 개발된 일반적인 원칙 사용
- 내부 구조는 운영체제마다 다를 수 있음
- 기법(Mechanism)과 정책(Policy)
- 중요한 설계 원칙: 기법과 정책의 분리
- 기법: 어떻게 할 것인가? (How)
- 정책 변경에 민감하지 않는 일반적인 것이 바람직
- 정책: 무엇을 할 것인가? (What)
- 시간이 지남에 따라서 변경될 수 있음
- e.g. CPU 보호 방법
- 기법: CPU 보호를 위하여 타이머 구조 사용
- 정책: 특정 사용자를 위한 타이머 양 결정
- 기법과 정책의 분리는 flexibility를 위해서 중요
- 구현(Implementation)
- 운영체제의 구현
- 초기에는 어셈블리 언어로 작성
- 현재 대부분은 고급 언어로 작성
- system programs의 구현
- C, C++ 등 으로 작성됨
- 운영체제의 구현
- 고급 언어 구현의 장단점
- 장점
- 코드를 빠르게 작성
- 간결한 코드
- 이해와 디버깅이 쉬움
- 이식하기 훨씬 쉬움
- 단점이 문제가 안 되는 이유
- 컴파일러가 최적화 됨
- OS의 주된 성능 향상은 더 좋은 자료구조와 알고리즘에 의한 것
- 고성능이 중요한 소량의 코드만 어셈블리 코드로 대체
- 장점
- Simple Structure (단층 구조)
- monolithic 구조 - 많은 기능들이 하나의 계층
- 많은 상용 운영체제, 잘 정의된 구조를 갖지 않음
- MS-DOS
- UNIX
- Layered Structure (계층 구조)
- 운영체제가 여러 계층으로 구분
- 각 계층은 하위 계층 위에 구축됨
- 장점 - 구현과 디버깅이 간단, 하위계층 연산이 어떻게 구현되어 있는지 알 필요 X, 무슨 동작만 하는지 알면 됨 ex) 네트워크 프로토콜, 웹 구현
- 단점 - 각 계층을 적절히 정의하는 것이 어렵고, 명확하지 않을 수 있음, 덜 효율적, 요즘 부정적
- Microkernel
- 필수적이 아닌 많은 부분을 사용자 공간으로 이동 → Small Kernel
- 개발 이유: UNIX 커널 확장되면서 관리 어려움
- 장점: 확장 용이, 운영체제 이식 용이, 높은 신뢰성과 보안성
- 단점: 시스템 함수 오버헤드로 인한 성능 저하
- 기본 기능
- 사용자 모듈과 사용자 공간에서 수행하는 서비스 간에 통신 기능 제공 → Message Passing 사용
- Modules
- kernel 구성
- a set of core components + loadable kernel modules
- loadable kernel module (LKM)
- 부팅 또는 실행시간 동안 동적으로 적재되어 커널 기능 확장
- 대부분 현대 운영체제에서 구현됨
- 모듈 인터페이스의 특징
- 각 core component가 분리됨
- 알려진 인터페이스를 통하여 다른 component/module과 통신
- layered 구조와 유사하지만 더 유연성 있음
- microkenel approach와 유사하지만 더 효율
- kernel 구성
- 장애 분석
- log file - 프로세스가 실패하면 오류 정보를 기록
- core dump - 오류 발생 프로세스의 메모리 저장
- crash dump - 커널 장애→커널 메모리 내용 저장
- 성능 조정도 디버깅 작업에 포함
- 병목 지점을 제거하여 시스템 성능 최적화 가능
- 추적
- dtrace
- strace
- Bootstarpping(booting)
- 커널을 적재하여 컴퓨터 시작하는 절차
- Bootstrap loader
- 커널을 찾아서 메모리에 적재하고 수행을 시작하는 일, ROM에 저장된 코드
- 시스템 진단 작업 수행, 전체 초기화 후 운영체제 시작시킴
- Firmware
- bootstarp 코드 변경 가능을 위해 ROM 대신 EPROM에 저장
- 하드웨어와 소프트웨어의 중간 특성
- RAM에서 실행하는 거보다 느려서 RAM에 복사하여 실행
- 보통 운영체제는 디스크에 저장하지만, 일부 시스템(smartphone, game console)은 EPROM/flash 저장
- 시스템 부트 과정
- 2.1 사용자를 위한 서비스
- 사용자 인터페이스
- 프로그램 실행
- 입출력 작업
- 파일 시스템 연산
- 통신
- 프로세스 간 정보를 교환
- 정보 교환 방법
- 공유 메모리(Shared Memory) 경유 - 동일 컴퓨터
- 메시지 전송(Meesage Passing) 경유 - 동일/다른 컴퓨터
- 오류 탐지
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 시스템 정지
- 오류 발생 프로세스 종료 - 오류코드 반환
- 오류 원인 제거 후 재실행
- 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 각 오류에 대해서 적절한 조치를 취해야함
- 자원 할당
- 회계
- 보호와 보안
- 명령어 해석 - command line interface(CLI)
- command를 입력 받아서 수행
- 구현 방법
- 커널에 포함되어 구현, 또는 작업이 시작되거나, 로그온할 때에 대화형으로 수행되는 특수한 (시스템) 프로그램으로 구현
- 명령어 처리의 구현
- 내장 명령어
- 유틸리티 명령어
- 시스템 관리자, 파워 유저가 많이 사용 - 작업에 빨리 접근, 효울적
- 프로그램 기능이 있어서 반복적 작업에 효과적 → 셸 스크립트
- 그래픽 사용자 인터페이스 (GUI)
- 사용하기 쉬움
- 사용자 인터페이스는 대개 OS의 직접적인 기능이 아님
- 대게, 운영체제 시스템 구조에 포함되지 않음
- 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공
- 운영체제 프로그래밍 인터페이스
- 대개 C/C++와 같은 고급 언어 루틴 형태로 제공
- 프로그래머가 시스템 호출에 대한 C/C++ 함수를 호출하여 사용
- 서비스를 수행하는 저수준의 작업은 시스템호출 명령어를 포함하는 어셈블리 코드를 포함하여 작성됨
- MS-DOS는 시스템 호출 명령어를 사용하는 어셈블리언어 프로그램으로 운영체제 서비스를 요청하도록 되어있음
- 응용 프로그래밍 인터페이스 (API)
- 응용 프로그래머에서 사용 가능한 함수의 집합을 지정 (라이브러리 형태)
- 시스템 호출보다 API를 더 많이 사용하는 이유
- 프로그램 이식성
- 사용하기 쉬움
- 시스템 호출의 구현
- 각 시스템 호출에 번호가 부여됨
- 시스템 호출 인터페이스
- 매개 변수 전달 받음
- 관련된 시스템 호출을 호출
- status와 반환 값 반환
- 운영체제 인터페이스의 상세 내용은 API에 의해서 숨겨짐 → 사용자는 API 매개변수 규칙을 준수하고, 시스템 호출의 결과로 OS가 수행하는 작업에 대해서 이해하면 됨
- 시스템 호출 매개변수 전달
- 시스템 호출의 중요 범주
- 프로세스 제어
- 프로세스 생성/적재/실행/종료, 중지
- 속성 읽기/설정, 메모리 할당/반납
- 시간,사건 대기, 사건 알림
- 파일 관리
- 파일 생성, 삭제, 열기, 닫기 등
- 속성 읽기/설정
- 장치 관리
- 장치 요구, 반납, 읽기, 쓰기, 위치 변경
- 속성 읽기/설정, 논리적 부착/분리
- 정보 유지보수
- 통신
- 통신 연결 생성/삭제
- 메시지 송신, 수신, 상태 정보 전달
- 원격 장치 부착/분리
- 보호
- 네트워크와 인터넷 연결로 모든 컴퓨터 시스템에서 보호를 고려해야
- 프로세스 제어
- single-tasking 시스템: MS-DOS
- single-tasking 시스템: Arduino
- multi-tasking 시스템: UNIX/Linux
- 프로그램 개발과 실행을 위해 편리한 환경을 제공하는 프로그렘
- 설계 목표와 명세 정의
- 요구조건 지정 (설게 목표)
- 사용자 목표
- 시스템 목표
- 요구 조건은 애매하고 다양하게 해석될 수 있으며, 일반적으로 합의된 유일한 해법은 없음
- 운영체제의 설계 및 구현
- 모든 요구 조건을 해결하는 완전한 해결책은 없지만, 다양한 요구 조건에 대한 성공이 입증된 다양한 접근법은 있다.
- 소프트웨어 공학에서 개발된 일반적인 원칙 사용
- 내부 구조는 운영체제마다 다를 수 있음
- 기법(Mechanism)과 정책(Policy)
- 중요한 설계 원칙: 기법과 정책의 분리
- 기법: 어떻게 할 것인가? (How)
- 정책 변경에 민감하지 않는 일반적인 것이 바람직
- 정책: 무엇을 할 것인가? (What)
- 시간이 지남에 따라서 변경될 수 있음
- e.g. CPU 보호 방법
- 기법: CPU 보호를 위하여 타이머 구조 사용
- 정책: 특정 사용자를 위한 타이머 양 결정
- 기법과 정책의 분리는 flexibility를 위해서 중요
- 구현(Implementation)
- 운영체제의 구현
- 초기에는 어셈블리 언어로 작성
- 현재 대부분은 고급 언어로 작성
- system programs의 구현
- C, C++ 등 으로 작성됨
- 운영체제의 구현
- 고급 언어 구현의 장단점
- 장점
- 코드를 빠르게 작성
- 간결한 코드
- 이해와 디버깅이 쉬움
- 이식하기 훨씬 쉬움
- 단점이 문제가 안 되는 이유
- 컴파일러가 최적화 됨
- OS의 주된 성능 향상은 더 좋은 자료구조와 알고리즘에 의한 것
- 고성능이 중요한 소량의 코드만 어셈블리 코드로 대체
- 장점
- Simple Structure (단층 구조)
- monolithic 구조 - 많은 기능들이 하나의 계층
- 많은 상용 운영체제, 잘 정의된 구조를 갖지 않음
- MS-DOS
- UNIX
- Layered Structure (계층 구조)
- 운영체제가 여러 계층으로 구분
- 각 계층은 하위 계층 위에 구축됨
- 장점 - 구현과 디버깅이 간단, 하위계층 연산이 어떻게 구현되어 있는지 알 필요 X, 무슨 동작만 하는지 알면 됨 ex) 네트워크 프로토콜, 웹 구현
- 단점 - 각 계층을 적절히 정의하는 것이 어렵고, 명확하지 않을 수 있음, 덜 효율적, 요즘 부정적
- Microkernel
- 필수적이 아닌 많은 부분을 사용자 공간으로 이동 → Small Kernel
- 개발 이유: UNIX 커널 확장되면서 관리 어려움
- 장점: 확장 용이, 운영체제 이식 용이, 높은 신뢰성과 보안성
- 단점: 시스템 함수 오버헤드로 인한 성능 저하
- 기본 기능
- 사용자 모듈과 사용자 공간에서 수행하는 서비스 간에 통신 기능 제공 → Message Passing 사용
- Modules
- kernel 구성
- a set of core components + loadable kernel modules
- loadable kernel module (LKM)
- 부팅 또는 실행시간 동안 동적으로 적재되어 커널 기능 확장
- 대부분 현대 운영체제에서 구현됨
- 모듈 인터페이스의 특징
- 각 core component가 분리됨
- 알려진 인터페이스를 통하여 다른 component/module과 통신
- layered 구조와 유사하지만 더 유연성 있음
- microkenel approach와 유사하지만 더 효율
- kernel 구성
- 장애 분석
- log file - 프로세스가 실패하면 오류 정보를 기록
- core dump - 오류 발생 프로세스의 메모리 저장
- crash dump - 커널 장애→커널 메모리 내용 저장
- 성능 조정도 디버깅 작업에 포함
- 병목 지점을 제거하여 시스템 성능 최적화 가능
- 추적
- dtrace
- strace
- Bootstarpping(booting)
- 커널을 적재하여 컴퓨터 시작하는 절차
- Bootstrap loader
- 커널을 찾아서 메모리에 적재하고 수행을 시작하는 일, ROM에 저장된 코드
- 시스템 진단 작업 수행, 전체 초기화 후 운영체제 시작시킴
- Firmware
- bootstarp 코드 변경 가능을 위해 ROM 대신 EPROM에 저장
- 하드웨어와 소프트웨어의 중간 특성
- RAM에서 실행하는 거보다 느려서 RAM에 복사하여 실행
- 보통 운영체제는 디스크에 저장하지만, 일부 시스템(smartphone, game console)은 EPROM/flash 저장
- 시스템 부트 과정
- 2.10 시스템 부트
- 2.8 운영체제 디버깅
- 2.7 운영체제 구조
- 2.6 운영체제 설계와 구현
- ====================================
- 2.5 시스템 프로그램
- ====================================
- 2.4 시스템 호출의 유형
- 2.3 시스템 호출(System Call)
- 2.2 사용자 운영체제 인터페이스
- 2.10 시스템 부트
- 2.8 운영체제 디버깅
- 2.7 운영체제 구조
- 2.6 운영체제 설계와 구현
- ====================================
- 2.5 시스템 프로그램
- ====================================
- 2.4 시스템 호출의 유형
- 2.3 시스템 호출(System Call)
- 2.2 사용자 운영체제 인터페이스
- 2.10 시스템 부트
- 2.8 운영체제 디버깅
- 2.7 운영체제 구조
- 2.6 운영체제 설계와 구현
- ====================================
- 2.5 시스템 프로그램
- ====================================
- 2.4 시스템 호출의 유형
- 2.3 시스템 호출(System Call)
- 2.2 사용자 운영체제 인터페이스
- 2.10 시스템 부트
- 2.8 운영체제 디버깅
- 2.7 운영체제 구조
- 2.6 운영체제 설계와 구현
- ====================================
- 2.5 시스템 프로그램
- ====================================
- 2.4 시스템 호출의 유형
- 2.3 시스템 호출(System Call)
- 2.2 사용자 운영체제 인터페이스
- 2.10 시스템 부트
- 2.8 운영체제 디버깅
- 2.7 운영체제 구조
- 2.6 운영체제 설계와 구현
- ====================================
- 2.5 시스템 프로그램
- ====================================
- 2.4 시스템 호출의 유형
- 2.3 시스템 호출(System Call)
- 2.2 사용자 운영체제 인터페이스
- 2.10 시스템 부트
- 2.8 운영체제 디버깅
- 2.7 운영체제 구조
- 2.6 운영체제 설계와 구현
- ====================================
- 2.5 시스템 프로그램
- ====================================
- 2.4 시스템 호출의 유형
- 2.3 시스템 호출(System Call)
- 2.2 사용자 운영체제 인터페이스
- 2.10 시스템 부트
- 2.8 운영체제 디버깅
- 2.7 운영체제 구조
- 2.6 운영체제 설계와 구현
- ====================================
- 2.5 시스템 프로그램
- ====================================
- 2.4 시스템 호출의 유형
- 2.3 시스템 호출(System Call)
- 2.2 사용자 운영체제 인터페이스
- 2.10 시스템 부트
- 2.8 운영체제 디버깅
- 2.7 운영체제 구조
- 2.6 운영체제 설계와 구현
- ====================================
- 2.5 시스템 프로그램
- ====================================
- 2.4 시스템 호출의 유형
- 2.3 시스템 호출(System Call)
- 2.2 사용자 운영체제 인터페이스
- 2.10 시스템 부트
- 2.8 운영체제 디버깅
- 2.7 운영체제 구조
- 2.6 운영체제 설계와 구현
- ====================================
- 2.5 시스템 프로그램
- ====================================
- 2.4 시스템 호출의 유형
- 2.3 시스템 호출(System Call)
- 2.2 사용자 운영체제 인터페이스
- 2.10 시스템 부트
- 2.8 운영체제 디버깅
- 2.7 운영체제 구조
- 2.6 운영체제 설계와 구현
- ====================================
- 2.5 시스템 프로그램
- ====================================
- 2.4 시스템 호출의 유형
- 2.3 시스템 호출(System Call)
- 2.2 사용자 운영체제 인터페이스
- 2.10 시스템 부트
- 2.8 운영체제 디버깅
- 2.7 운영체제 구조
- 2.6 운영체제 설계와 구현
- ====================================
- 2.5 시스템 프로그램
- ====================================
- 2.4 시스템 호출의 유형
- 2.3 시스템 호출(System Call)
- 2.2 사용자 운영체제 인터페이스
