본문 바로가기

운영체제

운영체제 구조

  1. 운영체제 서비스
  2. 사용자와 운영체제 인터페이스
  3. 시스템 콜
  4. 시스템 서비스
    1. 파일관리
    2. 상태 정보
    3. 파일 변경
    4. 프로그래밍 언어지원
    5. 프로그램 적재와 수행
    6. 통신
    7. 백그라운드 서비스
  5. 링커와 로더
  6. 응용 프로그램이 운영체제마다 다른 이유
  7. 운영체제 설계 및 구현
    1. 설계 목표
    2. 기법과 정책
    3. 구현

 

시스템 서비스

시스템 서비스는 시스템 유틸리티로도 알려진 프로그램 개발과 실행을 위해 더 편리한 환경을 제공한다.

파일관리

 파일과 디렉터리를 생성, 삭제, 복사, 개명, 인쇄, 열거, 조작한다.

 

상태정보

 날짜, 시간, 메모리, 사용자 수 등과 같은 상태정보.

 상세한 성능, 로깅 및 디버깅 정보 등 제공.

 정보를 포맷하여 인쇄하거나 GUI 윈도에 표시

 혹은 환경 설정 정보를 저장하고 검색할 수 있는 등록(registry)기능 지원.

 

파일변경

 파일의 내용을 생성하고 변경하기 위해 문장 편집기 사용.

 파일의 내용을 검색하거나 변환하기 위한 특수 명령어 제공

 

프로그래밍언어지원

 프로그래밍 언어들에 대한 컴파일러, 어셈블러, 디버거 및 해석기가 OS와 함께 제공되거나 별도로 다운로드.

 

프로그램 적재와 수행

 프로그램이 수행되려면 메모리에 적재되어야 함.

 absolute loader, relocatable loader, linkage editor, overlay loader 등 제공

 고급어나 기계어를 위한 디버깅 시스템 필요.

 

통신

 프로세스, 사용자, 컴퓨터 시스템 간 가상 접속을 이루기 위한 기법 제공.

 ex) 다른 사용자에게 메세지 전송, 웹페이지 읽기, 이메일 전송, 원거리 로그인, 파일 전송 등

 

백그라운드 서비스

 시스템 부트를 할 때 특정 시스템 프로그램을 시작시킬 방법이 있음.

 시스템이 정지될 때까지 계속 실행하는 프로세스도 존재

 항상 실행되는 시스템 프로그램 프로세스는 서비스, 서브시스템, 디먼.

 ex) 네트워크 디먼. 시스템은 연결 요청을 올바른 프로세스에게 연결하기 위해 네트워크 연결을 청취하는 서비스 필요.

 ex) 스로세스 스케줄러, 시스템 오류 감시 서비스, 출력 서버 등

 전형적인 시스템은 수십 개의 디먼을 가짐. OS가 중요한 활동을 사용자 문맥(커널 문맥이 아닌)에서 실행해야 하는 경우, 디먼을 이용해 작업 수행 가능.

 

링커와 로더

일반적으로 프로그램은 디스크에 이진 실행 파일로 존재한다.

CPU에서 실행하려면, 프로그램을 메모리로 가져와 프로세스 형태로 배치되어야 한다.

프로그램 컴파일 - 메모리에 배치 - CPU 코어에서 실행

 

소스 파일은 물리 메모리 위치에 로드되도록 설계된 오브젝트 파일로 컴파일된다. (재배치 가능 오브젝트 파일)

링커는 재배치 가능 오브젝트 파일을 하나의 이진 실행 파일로 결합한다.

다른 오브젝트 파일 또는 라이브러리도 포함된다.

로더는 이진 실행 파일을 메모리에 로드하는 데 사용되며, CPU 코어에서 실행할 수 있는 상태가 된다.

 

재배치

( 링커, 로더 ) 

링크 및 로드와 관련된 활동은 재배치다.

프로그램 부분에 최종 주소를 할당한다.

프로그램 코드와 데이터를 해당 주소와 일치하도록 조정한다.

런타임에 코드가 라이브러리 함수를 호출하고 변수에 접근할 수 있게 한다.

 

소스 프로그램 ( main.c )

컴파일러 ( gcc -c main.c )

오브젝트 파일 ( main.o )

링커 ( gcc -o main main.o -lm )

실행 파일 ( main )

로더 ( ./main )

메모리의 프로그램

 

로더를 실행하려면 명령어 라인에 실행 파일의 이름을 입력하기만 하면 된다.

 

ex ) UNIX 시스템 CLI

 

프로그램 이름 입력

fork( ) 시스템콜 - 새 프로세스 생성

exec( ) 시스템콜 - 로더 호출, exec ( ) 에 파일 이름 전달

로더 - 프로세스의 주소 공간 사용해 지정된 프로그램을 메모리에 적재(load)

( GUI 인터페이스에서도 유사한 메커니즘 사용 )

 

지금까지 설명한 과정에서는 모든 라이브러리가 실행 파일에 링크되어 메모리에 적재.

실제 대부분 시스템에서 프로그램이 적재될 때 라이브러리를 동적으로 링크

ex) Windows 에서의 DDL(dynamically linked libraray, 동적 링킹 라이브러리) - 메모리 사용 절약

 

오브젝트 파일 및 실행 파일은 일반적으로 표준화된 형식을 가진다.

ex) UNIX 및 Linux system - ELF(Executable and Linkable Format)

 

응용 프로그램이 운영체제마다 다른 이유

기본적으로 한 운영체제에서 컴파일된 응용 프로그램은 다른 운영체제에서 실행할 수 없다.

각 운영체제는 고유한 시스템 콜 집합을 제공한다. - 운영체제가 제공하는 서비스 집합의 일부이다.

다른 운영체제에서 실행하기 어렵다.

 

응용 프로그램이 여러 운영체제에서 실행될 수 있는 방법

1. 인터프리터 언어로 응용프로그램 작성. 성능 저하, 기능 제한의 단점.

2. 가상 머신. 가상머신은 언어의 RTE 중 하나이다. ( Java 는 로더, 바이트코드 검증기 및 Java 응용 프로그램을 Java 가상 머신으로 적재하는 기타 구성요소를 RTE로 가지고 있다. ) 인터프리터와 유사한 단점을 가진다.

3. 컴파일러가 기기 및 운영체제 고유의 이진 파일을 생성하는 표준 언어 또는 API를 사용할 수 있다.( UNIX OS 변종 간 호환성 유지를 위한 POSIX API와 표준 집합 )

 

이동성 부족. 크로스 플랫폼 응용 프로그램을 개발하는 것이 어려운 작업이다.

시스템의 낮은 수준에서 또 다른 어련운 점.

- 각 운영체제는 헤더, 명령어 및 변수의 배치를 강제하는 응용 프로그램 이진 형식이 있다. 명시된 구조 형태. 실행 파일 내 특정 위치에 있어야 올바로 실행.

- CPU는 다양한 명령어 집합을 가진다. 해당 명령어가 포함된 응용 프로그램만 올바로 실행.

- 운영체제마다 시스템콜. 피연산자, 피연산자 순서, 시스템콜 호출 방법, 시스템콜 번호, 의미, 반환 결과 등 여러 측면에서 운영체제마다 다르다.

 

ELF는 Linux 및 UNIX 시스템에서 공통 표준을 제공하지만 보장은 없다.

 

API는 응용 프로그램 수준에서 특정 기능을 지정한다.

아키텍처 수준에서 이진코드의 여러 구성요소가 주어진 아키텍처에서 특정 운영체제와 상호 작용할 수 있는 방법 정의 - ABI ( application binary interface ).

ABI는 하위 수준의 세부 정보를 명시한다.

ABI는 특정 아키텍처에 대해 명시된다. ( ex. ARMv8 프로세서에 대한 ABI )

ABI는 아키텍처 수준의 API이다.

ABI는 플랫폼 간 호환성을 거의 제공하지 않는다. 

 

요약. 특정 CPU 유형, 특정 운영체제에서 인터프리터, RTE 또는 이진 실행 파일을 작성하고 컴파일하지 않으면 응용프로그램이 실행되지 않는다. 

 

 

운영체제 설계 및 구현

운영체제의 설계와 구현에 대한 완전한 해결책은 없다. ( not "solvable" )

그러나 성공적인 접근 방법들이 있다.

 

설계 및 목표 

시스템의 목표와 명세를 정의에서 시작

최상위 수준에서 하드웨어와 시스템 유형에 영향 받음

 

사용자 목적 - 운영체제는 사용하기 쉽고, 편리하고, 배우기 쉽고, 믿을 수 있고, 안전하고, 신속해야 한다.

시스템 목적 - 운영체제는 설계, 구현, 유지 보수가 쉬어야 하고, 적응성, 신뢰성, 무요류, 효율성을 가져야 한다.

 

운영체제 요구 정의에 유일한 해법은 없다. 소프틍웨어 공학 분야에 일반적인 원칙들이 존재한다.

 

 

기법과 정책 

기법(mechanism)으로부터 정책(policy)를 분리해야 한다.

기법 - 어떤 일을 어떻게 할 것인가를 결정하는 것 (how)

정책 - 무엇을 할 것인가를 결정하는 것 (what)

 

ex) 타이머 구조. CPU 보호를 보장하기 위한 기법이다. 특정 사용자를 위해 타이머를 얼마나 오래 설정할지 결정하는 것은 정책적 결정이다.

정책과 기법의 분리는 융통성을 위해 아주 중요하다. 충분한 융통성이 있는 일반적인 기법이 더 바람직하다.

 

정책 결정 - 자원 할당 문제에서 중요하다.

기법 결정 - 질문이 무엇(what)이 아니라 어떻게(how)일 때 

 

 

구현

운영체제의 설계과 완료되면 구현

일반적인 언급 어렵다

초기 - 어셈블리

이제 - c or c++ 고급언어

 

실제, 이 둘 이상의 고급 언어가 종종 사용

커널 최하위 레벨 - 어셈블리 or C

상위 레벨 루틴 - C and C++

시스템 라이브러리 - C++ or 상위 레벨 언어

 

ex) 안드로이드

커널 - 어셈블리, C

시스템 라이브러리 - C, C++

응용 프로그램 프레임워크 - Java

 

운영체제를 고급 수준 언어로 - 단점. 속도가 느리다. 저장 장치가 많이 소요.