[23-01/운영체제] 컴퓨터 시스템과 운영체제

1. 컴퓨터 시스템과 하드웨어

컴퓨터 시스템을 구성하는 계층

 

컴퓨터 시스템의 범위

■ 컴퓨터 시스템의 계층

- 응용 프로그램 층

- 운영체제 층

- 컴퓨터 하드웨어 층

 

■ 컴퓨터 시스템 계층 구조의 특징

- 사용자는 응용프로그램과 GUI/도구프로그램(툴 / 유틸리티)을 통해 컴퓨터 활용

- 하드웨어는 모두 운영체제의 배타적 독점적 지배 받음

- 사용자나 응용프로그램의 하드웨어에 대한 직접 접근 불허 ( 반드시 운영체제 통해서만 접근 가능 )

 

■ 계층 구조로 보는 운영체제의 기능

- 사용자가 하드웨어에 대해 몰라도 컴퓨터를 사용할 수 있도록 함

- 응용프로그램과 하드웨어 사이의 중계

    - 위로는 응용프로그램과 아래로는 하드웨어와의 인터페이스

 

컴퓨터 하드웨어 구성

 

컴퓨터 하드웨어 설명

■ CPU (Central Processing Unit)

- 프로그램 코드(기계 명령)를 해석하여 실행하는 중앙처리장치

- 컴퓨터의 가장 핵심 장치

- 전원이 공급될 때 작동 시작, 메모리에 적재된 프로그램 실행

 

■ 메모리

- CPU에 의해 실행되는 프로그램 코드와 데이터가 적재되는 공간

- 반도체 메모리 RAM (요즘 메모리는 다 반도체)

- 프로그램은 실행되기 위해 반드시 메모리에 적재되어야 함.

 

■ 캐시 메모리 (Cache Memory)

- 배경

    - CPU 처리속도가 메모리 속도에 비해 빠르게 발전 -> 느린 메모리 때문에 CPU의 대기 시간이 늘게 되었음

    - CPU의 프로그램 실행 속도를 높이기 위해, CPU와 메모리 사이에 소량의 빠른 메모리를 설치하게 되었음.

- 온칩 캐시 (on-chip) : CPU 내부에 만들어진 캐시, 오늘날 대부분 온칩 캐시 L1, L2, L3

- 옵칩 캐시 (off-chip) : CPU 외부에 설치되는 캐시

- 캐시 메모리가 있는 경우 CPU는 캐시 메모리에서만 프로그램 실행

    - 실행하고자하는 프고르매과 데이터는 메모리에 먼저 적재되고 다시 캐시로 옮겨져야 함

    - 캐시는 용량이 작기 때문에 현재 실행할 코드와 데이터의 극히 일부분만 저장

 

■ 장치들

- 키보드, 프린터, 스캐너 등

 

■ 버스 (bus)

- 하드웨어들이 데이터를 주고받기 위해 0과 1의 디지털 신호가 지나가는 여러 가닥의 선을 다발로 묶어 부르는 용어

- 컴퓨터의 버스 : 도로 / 컴퓨터의 데이터 : 도로에 다니는 자동차

 

● 버스의 종류 (버스에 지나다니는 정보에 따라) ★

1. 주소 버스 (address bus) : 주소 신호가 지나다니는 버스(도로)
2. 데이터 버스 (data bus) : 데이터 신호가 지나다니는 버스(도로)
3. 제어 버스 (control bus) : 제어 신호가 지나다니는 버스(도로)

● 주소

- 메모리, 입출력 장치나 저장 장치 내에 있는 저장소에 대한 번지

- 0번지에서 시작하는 양수

- 주소 버스는 주소 값이 전달되는 여러 선의 다발

- CPU는 메모리나 입출력 장치에 값을 쓰거나 읽을 때 반드시 주소를 발생시킴

 

■ 목적에 따라 버스 구분

1. 시스템 버스 (System Bus)

- CPU, 캐시 메모리, 메모리 등 빠른 하드웨어들 사이에 데이터 전송

- 고속도로에 비유

2. 입출력 버스 (I/O Bus) PCIe

- 상대적으로는 느린 입출력 장치들로부터 입출력 데이터 전송

- 일반 도로에 비유

 

■ I/O controllers

-> 입출력 장치들을 제어하기 위한 여러 하드웨어

- 입출력 장치에게 명령 하달

- 메모리와 입출력 장치 사이에 데이터 전달 중계

- DMAC (Direct Memory Access Controller), 인터럽트 제어장치 (Interrupt Controller, INTC) 등 포함

 

현대 PC의 구조

 

CPU와 메모리의 관계

■ CPU

- 능동적 소자. 메모리 액세스 시 주소 발생

 

■ 32비트 CPU, 32비트 운영체제, 32비트 컴퓨터란?

1) CPU에 32개의 주소선 있음

- CPU의 액세스 범위 : 2³²개의 서로 다른 주소(0 ~ 2³²-1 번지)

-CPU가 최대 액세스할 수 있는 메모리의 크기 : 4GB

- 한 번지의 공간이 1바이트이므로, 2³²개의 주소 = 2³² 바이트 = 4GB

- 32비트 CPU를 가진 컴퓨터에 4GB이상 메모리를 설치할 경우 (4GB를 넘어선 영역은 사용할 수 없음)

2) CPU에 입출력되는 32개의 데이터 선 있음

- 한 번에 32비트 읽고 쓰기 가능 (32비트는 4개의 주소)

 

CPU 기계 명령 (instruction)

■ CPU 명령

- CPU가 해석하고 실행할 수 있는 기계 명령 (machine instruction)

- C언어나 자바의 프로그램 소스 코드와 다름

- CPU를 설계하는 기업이 명령어들, 명령어 개수, 형태 등을 결정

- CPU의 명령 개수는 수십개~수백개

- CPU마다 명령 이름, 기계어 코드, 크기, 개수 등이 다름

- CPU 사이에 명령들의 호환성 없음

 

CPU의 일생 - 명령 처리 과정

■ CPU 레지스터들

- PC (Program Counter) : 다음에 실행할 명령의 메모리 주소 저장

- IR (Instruction Register) : 현재 실행하기 위해 메모리로부터 읽어 온 명령 저장

- SP (Stack Pointer) : 스택의 톱 메모리 주소 저장

- 데이터 레지스터들(Data Registers) : 연산에 사용되거나 사용될 데이터들 저장

- 상태 레지스터 (Status Register) - CPU의 상태 정보나 인터럽트 금지 등의 제어 정보 저장

- 기타 여러 레지스터 - 페이지 테이블이 저장된 메모리 주소를 가리키는 레지스터 등

 

■ CPU 명령 사이클 (instruction cycle) - CPU의 일생

- CPU가 하나의 명령을 실행하는 과정. CPU는 전원이 켜진 후 단순하게 명령 사이클 반복

 

스택(Stack)은 어디에 있는가?

■ 프로그램이 실행되기 위해 운영체제에 의해 할당되는 4공간

• 코드 (Code) 공간 - 프로그램 코드 적재
• 데이터 (Data) 공간 - 전역 변수들이 적재되는 공간
• 힙 (Heap) 공간 - 프로그램에서 동적 할당받는 공간 (자바 변수 동적)
• 스택(Stack) 공간 - 함수가 호출될 때 매개변수, 지역변수 등 저장

■ 스택

- 메모리의 일부를 스택으로 사용하도록 할당된 공간 (별도의 하드웨어 메모리가 있는 것은 아님)

- 운영체제는 각 프로그램에게 스택 공간 할당

- CPU의 SP 레지스터는 현재 CPU가 실행중인 프로그램의 스택 꼭대기 주소를 가리킴

- 스택에 저장되는 내용

• 함수의 지역 변수들
• 함수가 호출될 때 전달받은 매개변수 값들
• 함수가 실행된 후 돌아갈 주소
• 함수가 의도적으로 저장해두기 위한 값

컨텍스트 (Context)

- 컨텍스트(문맥이라고도 표현)

- 한 프로그램이 실행 중인 일체의 상황 혹은 상황 정보

- 메모리

    - 프로그램 코드와 데이터, 스택, 동적할당 받아 저장한 값

- CPU 레지스터들의 값

    - PC에는 코드의 주소, SP에는 스택의 주소, 다른 레지스터는 이전의 실행 결과나 현재 실행에 사용되는 데이터 들

- 축소 정의 : 현재 CPU에 들어 있는 레지스터의 값들 ( 메모리에 저장된 상황 정보는 그대로 있으니까 )

memo : 현재의 작업환경

 

■ 컨텍스트 스위칭

1. 발생

- CPU가 현재 프로그램의 실행을 중지하고 다른 프로그램을 실행할 때

- 여러개의 프로세스가 실행되고 있을 때 기존에 실행되던 프로세스를 중단하고 다른 프로세스를 실행하는 것 (실행할 프로세스의 교체기술)

2. 과정

- 현재 실행중인 프로그램의 컨텍스트(CPU레지스터들의 값)를 메모리에 저장

- 새로 실행시킬 프로그램의 저장된 컨텍스트(CPU레지스터들의 값)를 CPU에 복귀

 

 

멀티 코어 CPU (Multi-core CPU)

- 2001년 IBM에 의해 PowerPC라는 멀티코어 CPU 개발

- CPU 내부에 2개의 프로세서(processor) 포함

- 2개의 프로그램을 동시에 실행

- 코어는 완벽한 처리기 (과거 개념의 CPU)

 

 

 

2. 컴퓨터 시스템의 계층 구조와 운영체제 인터페이스

컴퓨터 시스템 계층

- 사용자

- 응용 프로그램

- 운영체제 ( 커널 코드, 디바이스 드라이버 )

- 하드웨어

 

컴퓨터 시스템이 계층 구조로 설계된 이유

- 계층간 독립성 확보(칸막이가 있다고 생각)를 위해

■ 사용자

- 운영체제나 하드웨어에 대해 몰라도 응용프로그램으로 컴퓨터 활용

 

■ 응용프로그램 

- 컴퓨터 하드웨어의 타입이나 구조, 제어 방법을 몰라도 개발 가능 ( 컴파일러는 예외 )

ex)

    - CPU 크기, 메모리 크기가 얼마인지 모르고 프로그램 작성

    - 저장 장치가 하드디스크인지 SSD인지, 저장 장치의 크기는 얼마인지, 디스크 헤드는 몇개 있는지 몰라도 파일 입출력 프로그램 작성

- 운영체제에게 요청하여 해결

- 컴퓨터 하드웨어가 바뀌어도 응용프로그램을 다시 작성할 필요 없음

memo : 있음. 필요 없도록 하는 것이 운영체제,

 

■ 운영체제

- 운영체제는 장치 관련된 모든 작업을 디바이스 드라이버에게 요청

- 응용 프로그램과 하드웨어 사이의 인터페이스

 

왜 운영체제가 필요한가?

■ 운영체제가 없다면 

- 응용프로그램이나 사용자가 직접 하드웨어를 제어해야 함.

- 하드웨어에 대한 지식이 필요하며 충돌, 관리, 보안의 문제 발생

 

■ 실례

- 2명이 동시에 프로그램 실행시키고자 할 때, 2개의 응용프로그램에 대한 스케줄링 - 프로세스 관리

- 응용프로그램이 메모리가 필요할 때, 메모리를 나누어 관리하고, 응용 프로그램 종료하면 메모리 회수 - 메모리 관리

- 2명의 사용자가 동시에 프린터에 프린팅을 시킬때, 장치 사용에 대한 충돌이 생기지 않도록 함 - 장치 관리

- 데이터를 파일에 기록할때, 하드 디스크의 기록할 위치, 해당 위치에 다른 프로그램이 접근하지 못하도록 함 - 파일 시스템 관리

- 키보드에서 키가 입력되면 실행 중인 여러 응용프로그램 중 어떤 응용프로그램에게 키를 전달할지 결정 - 입출력 관리

 

★ 운영체제의 필요성

- 자원에 대한 충돌 해결, 성능 최적화, 사용자의 시스템 사용 효율화

 

운영체제와 응용프로그램 사이의 관계

■ 응용프로그램

- 워드, 웹브라우저 등, 사용자가 컴퓨터를 활용하도록 작성된 다양한 프로그램들

 

■ 응용프로그램에 대한 운영체제의 역할

- 응용프로그램이 직접 하드웨어를 다루지 못하도록 차단

    - 운영체제가 하드웨어를 완벽히 독점 장악

    - 이유 : 다른 응용프로그램들 사이의 하드웨어 사용 충돌을 막기 위함.

- 응용프로그램이 하드웨어 사용하고자 할 때

    - 반드시 운영체제에게 요청 -> 운영체제가 대신하여 하드웨어 조작

    - 유일한 요청 방법 - 시스템 호출(System Call)

- 응용프로그램과 하드웨어 사이의 인터페이스

- 응용프로그램들의 실행 순서 제어

- 응용프로그램들 사이의 통신 중계

 

운영체제와 사용자의 관계

- 사용자는 응용프로그램을 통해 컴퓨터를 활용함 (탐색기, 메모장 등)

 

■ 사용자에 대한 운영체제의 역할

- 사용자가 하드웨어에 관한 지식이 없어도 컴퓨터 다루기 용이

-사용자가 하드웨어를 설치하거나 변경하는 것에 도움

- 사용자에게 컴퓨터 시스템을 사용할 편리한 인터페이스 제공 ( UI, 마우스, 음성 명령 등 )

- 컴퓨터의 사용을 돕는 여러 도구 응용프로그램(유틸리티) 제공 ( Windows의 탐색기와 작업 관리자, 리눅스의 쉘)

- 사용자 계정 관리

- 사용자의 컴퓨터 사용 시간 계산, 과금 처리 등

 

운영체제와 하드웨어의 관계

- 하드웨어를 제어하는 것은 전적으로 운영체제의 몫

-> 응용프로그램에서 printf("hello")는 디스플레이 장치에 "hello" 출력하는 일은 운영체제가 함

-> 응용프로그램에서 scanf()는 키보드로부터 문자를 입력받는 일은 운영체제가 함

 

■ 운영체제

- 사용자/응용프로그램과 하드웨어 사이의 중계자

- 하드웨어 제어는 전적으로 운영체제의 기능

• 하드디스크에서 파일을 읽거나 쓰기
• 마우스의 클릭
• 키보드 입력 받기
• 네트워크를 통한 데이터 전송 혹은 수신
• 디스플레이에 텍스트나 이미지, 그래픽 등 출력

운영체제의 전체 기능

1. 프로세스와 스레드 관리

- 프로세스/스레드의 실행, 일시 중단, 종료, 스케줄링, 컨텍스트 스위칭, 동기화

2. 메모리 관리

- 프로세스나 스레드에게 메모리 할당, 메모리 반환, 다른 프로세스/스레드로부터의 메모리 보호

- 메모리를 하드 디스크의 영역까지 확장하는 가상 메모리 기술

3. 파일 관리 혹은 파일 시스템 관리

- 파일 생성, 저장, 읽기, 복사, 삭제, 이동, 파일 보호

4. 장치 관리

- 키보드, 마우스, 프린터 등 입출력 장치, 하드 디스크 등 저장 장치 제어

- 입출력

5. 사용자 인터페이스

- 라인 기반 명령 입출력 창,  마우스와 그래픽 사용 GUI 인터페이스 제공

6. 네트워킹

- 네트워크 인지, 연결, 닫기, 데이터 송수신

7. 보호 및 보안

- 바이러스나 웜, 멀웨어(malware), 해킹 등의 외부 공격이나 무단 침입으로부터 보호

 

운영체제 구성

운영체제 = 커널 + 툴 + 디바이스 드라이버

 

■ 커널 (Kernel)

- 운영체제의 핵심 부분, 좁은 의미의 운영체제

- 부팅 후 메모리에 상주하는 코드와 데이터

- 운영체제의 핵심 기능 모두 구현

- CPU, Memory, MMU 등 컴퓨터 자원을 직접 제어하고 관리하는 코드와 자료 구조들

- 커널 코드는 함수들의 집합

- 커널 기능을 이용하려면 응용프로그램은 반드시 시스템 호출 사용

 

■ 도구(Tool) 소프트웨어와 GUI

- 사용자가 컴퓨터를 편리하게 사용할 수 있도록 제공하는 툴 소프트웨어 혹은 툴 응용프로그램

- Windows 경우, 바탕화면 GUI, 탐색기, 명령창, 작업 관리자, 제어판 등

- 리눅스의 경우, 

 

■ 디바이스 드라이버 (Device Driver)

- 장치를 직접 제어하고 입출력하는 소프트웨어

- 장치마다 전담 디바이스 드라이버 있음

- 일반적으로 장치 제작자에 의해 작성되어 배포됨

- 사례 : 키보드 드라이버, 디스크 드라이버, 마우스 드라이버, 그래픽 드라이버, 네트워크 드라이버 등

 

 

운영체제 커널 인터페이스

커널이 제공하는 2개 인터페이스 : 시스템 호출과 인터럽트

- 응용프로그램과 하드웨어 사이의 중계 역할

memo : 시스템 호출 - 함수 / 인터럽트 - 하드웨어 직접적인 접근

 

■ 시스템 호출 (System call)

- 커널과 응용프로그램 사이의 인터페이스

- 응용프로그램에서 커널 기능을 사용할 수 있는 유일한 방법

- 시스템 호출 라이브러리를 통해 다양한 시스템 호출 함수 제공

    - 시스템 호출 라이브러리는 운영체제 패키지에 포함됨

    - ex) 파일 읽기, 메모리 할당, 프로세스 정보 보기, 프로세스 생성 등

        - open(), close(), read(), write(), fork(), exit(), wait() 등의 시스템 호출 함수

 

■ 인터럽트 (Interrupt)

- 커널과 하드웨어 장치 사이의 인터페이스

- 장치들이 입출력 완료, 타이머 완료 등을 CPU에게 알리는 하드웨어적 방법

    - 인터럽트를 알리는 하드웨어 신호가 직접 CPU에 전달

● 인터럽트가 발생하면

- CPU는 하는 일을 중단하고 인터럽트 서비스 루틴 실행

- 인터럽트 서비스 루틴은 대부분 디바이스 드라이버 내에 있음

    - ex) 키 입력시 커널의 키보드 인터럽트 서비스 루틴 실행, 키를 읽어 커널 버퍼에 저장

- 인터럽트 서비스 루틴은 커널 영역에 적재

- 인터럽트 서비스 루틴은 실행을 마치면 하던 작업 계속함

● 인터럽트 활용

- 운영체제가 장치에게 지시한 입출력 작업의 완료, 예고 없는 네트워크 데이터의 도착, 키보드나 마우스의 입력, 부족한 배터리 경고 등 장치와 관련된 모든 이벤트 처리

 

3. 커널과 시스템 호출

응용프로그램의 자원 접근 문제

- 오늘날 운영체제는 다중프로그래밍 운영체제

    - 다수의 응용프로그램이 한 컴퓨터에서 동시에 실행

■ 문제

- 응용프로그램이 직접 컴퓨터 자원에 접근하면 충돌과 훼손 발생 ← 요즘 X

    - 다른 응용프로그램이 적재된 메모리 훼손 가능

    - 다른 응용 프로그램이 만든 파일 삭제 및 훼손 가능

    - 응용 프로그램이 커널이 적재된 영역 훼손 가능

■ 해결 방안

- 응용프로그램의 자원 접근 불허

- 자원에 대한 모든 접근은 커널에만 부여

 

● 구체적인 해결 방법

1. 메모리 공간을 사용자 공간과 커널 공간으로 분리

- 응용프로그램은 사용자 공간에 적재, 커널은 커널 공간에만 적재

2. CPU의 실행 모드를 사용자 모드와 커널 모드로 분리

- 응용프로그램은 사용자 모드에서만 실행, 커널 코드는 커널 모드에서만 실행

- 사용자 공간에서 커널 공간의 코드를 직접 접근하지 못하게 하기 위해

- 사용자 모드에서 커널 코드를 접근하면 응용프로그램 강제 종료

3. 응용프로그램이 커널 기능을 이용하고자 할 때, 시스템 호출을 이용해서만 커널 코드 이용

 

사용자 공간과 커널 공간

- 운영체제는 컴퓨터 메모리를 두 공간으로 분리

• 사용자 공간(User Space) : 모든 응용프로그램들이 나누어 사용하는 공간
  • 응용프로그램들이 적재되는 공간
• 커널 공간(Kernel Space) : 커널만 사용할 수 있는 공간
  • 커널 코드, 커널 데이터 등 커널에 의해 배타적으로 사용되는 공간
  • 디바이스 드라이버 포함

- 분리 이유 : 커널 코드와 데이터를 악의적인 응용프로그램이나 코딩 실수로부터 지키기 위함

 

사용자 공간 크기의 의미

■ 사용자 공간 크기

- 한 응용프로그램의 최대 크기 결정

    - 프로그램 코드 + 데이터(전역변수) + 힙(동적할당) + 스택 합친 크기

    - ex) 32비트 Windows 운영체제에서 사용자 공간 2GB란 -> 응용프로그램을 2GB 크기 이상 개발할 수 없음

 

■ 사용자 공간의 주소 범위

- 응용프로그램은 운영체제가 설정한 사용자 공간의 주소 범위를 넘어설 수 없음

ex) 32비트 Windows 운영체제에서 응용프로그램이

    0 ~ 7FFFFFFF 범위의 주소를 넘어 액세스하면 바로 종료(심각한 오류)

 

주소 공간은 가상 주소 공간

 

2가지 의문에 대한 해결

1. 사용자 공간의 충돌 해결

- 각 응용프로그램의 가상 주소 공간을 물리 주소 메모리에 매핑

    - 매핑 테이블은 운영체제가 소유하고 관리

- 물리 메모리를 여러 응용프로그램의 사용자 공간이 나누어 사용

    -실제 각 응용프로그램은 사용자 공간의 일부만 사용

- 커널 공간 역시 물리 메모리에 매핑

    - 각 응용프로그램의 매핑 테이블에 기록

    - 커널 공간에 대한 매핑 테이블 부분을 모든 응용프로그램에서 동일

 

2. 물리 메모리가 작은 경우에 대한 해결

- 운영체제는 물리 메모리를 하드디스크에 저장하여 물리 메모리의 빈 영역 확보 (가상 메모리 기법)

 

■ 가상 주소 공간 충돌을 막기 위한 가상 주소 공간의 물리 메모리 매핑

 

사용자 모드와 커널 모드 / 메모리 액세스

- CPU는 사용자 모드와 커널 모드 중 한 모드로 실행 ( CPU 내부에 모드 상태를 나타내는 '모드 레지스터' 있음

 

■ 사용자 모드 (User mode)

- CPU의 모드 비트 = 1

- CPU의 사용자 공간에 있는 코드나 데이터를 액세스하는 중

- CPU의 커널 공간 접근 불허 -> 응용프로그램으로부터 커널영역 보호

- 특권 명령(Privileged Instruction) 실행 불허

    - 특권 명령 - 입출력 장치 등 하드웨어나 시스템 중단 등 시스템 관련 처리를 위해 설계된 특별한 명령

■ 커널 모드 (Kernel mode, supervisor mode)

- CPU의 모드 비트 = 0

- CPU가 커널 공간에서 실행하는 중, 혹은 사용자 코드를 실행하는 중

- 특권 명령 사용 가능

 

사용자 모드에서 커널 모드로 전환

- 사용자 모드에서 커널 모드로 전환하는 경우 - 시스템 호출과 인터럽트 발생 2가지

 

■ 시스템 호출

- 시스템 호출을 실행하는 특별한 기계 명령에 의해 진행 (CPU마다 다름)

- 기계 명령이 CPU의 모드 비트를 커널 모드로 전환

 

■ 인터럽트

- CPU가 인터럽트를 수신하면 커널 모드로 자동 전환

    -인터럽트 서비스 루틴이 커널 공간에 있기 때문

- CPU는 인터럽트 서비스 루틴 실행

- 인터럽트 서비스 루틴이 끝나면 CPU는 사용자 모드로 자동 전환

 

사용자 모드와 커널 모드의 비교

	사용자 모드	커널 모드
CPU의 메모리 액세스 범위	사용자 공간에 국한 커널 공간 액세스 불가	커널 공간을 포함한 모든 메모리 공간
CPU의 하드웨어 액세스 여부	불가 (X)	모든 하드웨어 액세스 가능 (O)
CPU가 처리 가능한 명령	특권 명령을 제외한 모든 CPU 명령	특권 명령을 포함한 모든 CPU 명령
오류 발생 시 처리	사용자 프로그램만 실행 종료 시스템이 종료 되지 않으므로 안전	시스템에 심각한 오류가 발생한 것으로 시스템 종료

 

특권 명령

■ 특권 명령

- 입출력 장치로부터의 입출력(I/O), 시스템 중단, 컨텍스트 스위칭, 인터럽트 금지 등 특별한 목적으로 설계된 CPU 명령

- 커널 모드에서만 실행 가능

 

■ 특권 명령 종류

1. I/O 명령

- 하드웨어 제어 및 장치로부터의 입출력

- 사례) in eax, 300 ; I/O 포트 300 번지에서 값을 읽어 eax 레지스터에 저장

 

2. Halt 명령

- CPU의 작동을 중지시키는 명령. CPU를 유휴 상태로 만듦.

 

3. 인터럽트 플래그를 켜고 끄는 명령

- CPU 내에 있는 인터럽트 플래그 비트를 제어하여 CPU가 인터럽트를 허용하거나 무시하도록 지시

- 사례) cli (clear interrupt flag) / sti (set interrupt flag) 명령

4. 타이머 설정 명령

5. 컨텍스트 스위칭 명령

6. 메모리 지우기 명령

7. 장치 상태 테이블 수정 등의 명령

 

실행 모드와 관련된 다양한 이슈

1. 사용자 모드와 커널 모드는 CPU에 의해 구현되는가, 운영체제에 의해 구현되는가?

- 모드는 CPU에 의해 구현되고, 운영체제가 활용하는 기능

- CPU 내부에 모드를 나타내는 레지스터가 존재함

- 운영체제는 CPU 내부의 모드 레지스터를 이용해 영역을 지킴

 

2. 운영체제가 사용자 모드와 커널 모드로 나누어 작동시키는 이유는?

- 커널 공간( 커널 코드와 데이터)에 대한 보안과 보호 (악의적 사용자와 오류 프로그램으로부터 커널 공간 지킴)

- 사용자 프로그램은 사용자 모드에서 아무리 심각한 오류가 발생해도 사용자 프로그램만 종료. 시스템을 중단시키지는 못함.

 

3. 사용자 프로그램이 커널 코드를 호출하는 일이 있는가?

- 사용자 프로그램이 커널 코드를 직접 호출하는 것은 불가능함 (시스템 호출을 통해서만 가능)

 

4. CPU가 커널 모드와 사용자 모드 중 어떤 모드로 많이 실행될까?

- 시스템 전체 통계를 보면 커널 모드에서 많이 실행

    - 키보드에서 읽고 디스플레이 출력, 디스크나 네트워크 작업 등 장치 액세스의 경우가 많으면 커널 모드 시간 비율 높음

    - 아무 작업도 없을 때 실행되는 시스템 유휴 프로세스가 커널 모드에서 실행되기 때문

 

+ 추가 내용 정리

전체 CPU 사용시간 중 커널 모드로 작동한 시간 보기

연한 부분 : 전체 CPU 시간 / 진한 부분 : 커널 모드 시간

- 커널 모드의 시간 비율이 높은 대체적인 이유 : 아무 작업이 이루어지고 있지 않을 때, 커널 모드에서 실행되는 시스템 유휴 프로세스 때문

 

작업 관리자로 시스템 유휴 프로세스의 CPU 사용량 보기

- 작업 관리자 - 세부정보 - CPU 선택

 

커널의 실체

1. 커널은 부팅 시에 커널 공간에 적재된 함수들과 데이터 집합

- 커널은 컴파일된 바이너리 형태, 하드디스크 특정 영역에 저장, 부팅 시에 커널 공간의 메모리에 적재

2. 커널 코드는 함수들의 집합

- 커널의 존재 - 커널 모드에서 실행되는 함수들과 데이터들의 집합

* 현재 커널 코드를 실행하고 있는 것은 누구인가? app2 프로세스임. 커널 프로세스란 말은 없음. 커널은 프로세스가 아님.

3. 커널은 스스로 실행되는 프로세스인가? NO

- 커널은 함수들의 집합. 시스템 호출에 의해 호출되는 함수들

- 커널이 스케줄링함. (X)

    - 커널 프로세스가 실행되면서 주기적으로 스케줄링한다(X)

    - 시스템 호출과 인터럽트 서비스 루틴에 의해 커널 내 스케줄러 함수가 호출되어 실행(O)

4. 커널은 실행 중이다? NO

- 커널은 프로세스도 스레드도 아니므로 NO

- 커널이 실행 중임. (X)

    - 응용프로그램이 시스템 호출을 하여 커널 코드를 실행하고 있음(O)

    - 인터럽트가 발생하여 인터럽트 서비스 루틴이 실행되고 있음(O)

5. 커널은 스택이나 힙을 가지는가? NO

- 커널은 스택이나 힙을 가지는 주체가 아님. 그러므로 NO

- 스택이나 힙을 가지는 주체는 프로세스나 스레드

- 스레드마다 사용자 스택과 커널 스택 소유

    - 스레드가 생성될 때 프로세스의 사용자 공간에 사용자 스택 할당 (사용자 코드가 실행되는 동안 활용)

    - 스레드가 생성될 때 커널 공간에 커널 스택 할당 (스레드가 시스템 호출로 커널 코드 실행할 때 스택으로 활용)

 

응용프로그램 빌딩

■ 라이브러리 (Library)

- 응용프로그램에서 활용하도록 미리 작성된 함수들, 컴파일 되어 바이너리 형태로 제공되는 파일

- 개발자는 라이브러리 활용없이 응용프로그램 작성 불가능

 

■ 응용프로그램이 활용하는 라이브러리는 2가지 유형

1. 표준 라이브러리 (Standard Library)

- 사용자가 작성하기 힘든 함수 제공

- 운영체제나 컴퓨터 하드웨어에 상관없이 이름과 사용법 동일 (운영체제나 하드웨어, 컴파일러에 관계없이 호환)

 

2. 시스템 호출 라이브러리

- 시스템 호출 함수들 포함

- 시스템 호출 함수들은 시스템 호출을 진행하여 커널 모드로 바꾸고 커널로 진입하여 커널에 만들어진 함수 실행 (커널의 다양한 기능 수행)

- 운영체제마다 시스템 호출 함수의 이름이 서로 다름 (운영체제 비호환)

- 시스템 호출 함수를 커널 API (Application Programming Interface)라고 부름

 

사용자 코드와 라이브러리 코드의 링킹

■ 실행 파일이 만들어지는 과정

- 응용프로그램 코드는 라이브러리 코드와의 링킹을 거쳐 하나의 실행 파일로 만들어짐

■ 응용프로그램 실행

- 응용프로그램이 사용자 공간에 적재

    - 실행 파일 내 사용자 코드와 라이브러리 코드의 메모리 적재

    - 실행 파일 내 사용자 전역 변수와 라이브러리의 전역 변수 모두 메모리 적재

- 응용프로그램은 사용자 모드로 실행 시작

함수 호출과 시스템 호출

■ 함수 호출 (function call)로 라이브러리 활용

- 사용자 공간에 적재된 함수가 다른 함수 (표준 라이브러리나 시스템 호출 라이브러리의 함수 포함) 호출

- 사용자 공간에서, 사용자 모드에서 실행

● 함수 호출 과정

- 사용자 공간의 스택에 돌아올 주소, 매개변수 전달, 호출된 함수의 지역변수 생성

- 사용자 공간에 적재된 함수의 주소로 점프

- 함수가 끝나면 함수를 호출한 곳으로 복귀

 

■ 시스템 호출 (System call)로 커널 코드 실행

- 응용프로그램이 운영체제의 기능을 사용하고자 할 때, 커널에 작성된 함수 실행

- 시스템 호출 라이브러리에 포함된 시스템 호출 함수가 시스템 호출 일으킴

● 시스템 호출 과정

- 시스템 호출을 일으키는 특별한 기계 명령 실행

- 이 명령이 사용자 모드에서 커널 모드로 전환, 커널 함수마다 매겨진 고유 번호 전달

- 커널의 시스템 호출 핸들러 실행

- 시스템 호출 핸들러가 전달받은 커널 함수의 고유 번호 분석, 해당 커널 함수 호출

- 커널 함수에서 리턴할 때 사용자 모드로 전환, 사용자 프로그램으로 복귀

 

시스템 호출

■ 시스템 호출

- 사용자 공간의 코드에서 커널 서비스를 요청하는 과정

    - 사용자 공간의 코드가 커널 서비스를 요청하는 과정

    - 커널 콜 (Kernel call), 트랩 (trap)으로도 불림

    - 응용프로그램에서 커널 기능을 활용하도록 만들어 놓은 기능

- 운영체제는 시스템 호출 라이브러리 제공

    - 시스템 호출 함수 혹은 커널 API 포함

    - Unix/Linux의 커널 API - open(), read(), write(), fork(), exit()

    - Windows의 커널 API - CreateProcess(), WaitForSingleObject()

    - 대략 200개 이상의 시스템 호출 함수 있음

 

■ 시스템 호출을 일으키는 기계 명령 

- CPU마다 시스템 호출을 실행하는 특별한 기계 명령 제공

    - 시스템 호출 CPU 명령

- 사례

    - xint 0x80 - 인텔의 x86계열의 CPU, 32비트에서 사용
    - syscall/sysret - ADM에서 최초 구현. 64비트에서만 작동
    - sysenter/sysexit - Intel에서 최초 구현, X86/64 CPU, AMD

 

■ 표준 라이브러리를 통해 간접적으로 이루어지는 시스템 호출

- 응용프로그램 -> 시스템 호출 라이브러리의 시스템 호출 함수 -> 시스템 호출 CPU 명령

- 응용프로그램 -> 표준 라이브러리 함수 -> 시스템 호출 라이브러리의 시스템 호출 함수 -> 시스템 호출 CPU 명령

 

- read() 함수에 의해 시스템 호출이 일어나는 과정

 

시스템 호출 비용 : fread()와 read()의 비교

- 시스템 호출은 함수 호출에 비해 많은 시간 비용 (시스템 호출을 많이 할수록 프로그램 실행 속도 저하)

- 파일에서 1000바이트를 읽는 2가지 유형의 코드 있음

 

■ 표준 C 라이브러리 함수 fread()와 시스템 호출 read() 실행 비교

● 표준 C 라이브러리 함수, fread(fp, buf, size)의 동작 과정

- fread()를 처음 호출하면 라이브러리 내 버퍼(buffer)가 비어 있음

- read()를 호출하여 라이브러리 내 버퍼를 채움.

- 응용프로그램으로부터 요청 받은 크기(size)만큼 응용프로그램의 buf로 복사

- 라이브러리 버퍼가 비거나 부족하면 그때 다시 read() 호출

● 시스템 호출 함수, read(fd, buf, size)의 동작 과정

- 시스템 호출을 이용하여 커널 코드 실행

- 커널 코드에서 디스크 읽기

- 라이브러리를 거치지 않고 바로 buf로 읽어 들임

 

■ fread와 read()의 동작 과정 비교

 

시스템 호출에 따른 비용 정리

- 시스템 호출에 따른 비용은 매우 큼

-> 시스템 호출 함수에 전달할 데이터들을 CPU 레지스터에 저장

-> 사용자 모드에서 커널 모드로 전환

-> 시스템 호출 핸들러 실행

-> CPU 내 레지스터가 훼손되는 것을 막기 위해 스택에 저장

-> 시스템 호출 함수 실행

-> 스택에 저장해둔 레지스터 복귀

-> 사용자 모드로 복귀

 

-시스템 호출은 필연적이지만, 시스템 호출 횟수를 줄여야 응용프로그램의 실행 시간이 짧아지고, 시스템 입장에서 더 많은 프로그램을 실행시킬 수 있는 시간 확보 -> 시스템의 처리율 향상

	함수 호출	시스템 호출
메모리 영역	사용자 영역 코드에서 사용자 영역의 함수 호출	사용자 영역의 코드에서 커널 함수 호출
CPU 실행 모드	사용자 모드	사용자 모드에서 커널 모드로 전환
비용	함수 호출에 따른 비용	커널 모드로 전환하는 등 함수 호출에 비해 큰 비용

4. 운영체제와 인터럽트

인터럽트

- 입출력 장치들이 비동기적 사건을 CPU에게 알리는 행위

    - 비동기적이란 예정되지 않거나 발생시간을 예측할 수 없는 사건

    - 키보드 입력, 네트워크로부터 데이터 도착 등

- 하드웨어 인터럽트

    - 장치들이 어떤 상황 발생을 CPU에게 알리는 하드웨어 신호

    - CPU는 인터럽트를 수신하면 인터럽트 서비스 루틴 실행

- 소프트웨어 인터럽트

    - CPU 명령으로 발생시키는 인터럽트

    - 하드웨어 인터럽트를 수신한 것과 동일하게 처리

 

■ 컴퓨터에서 인터럽트 활용

- 마우스를 움직이거나 클릭하는 등 마우스 조작

- 키보드 입력

- 네트워크로부터 데이터 도착

- 하드디스크의 쓰기 종료

- 시스템 클럭으로부터 일정한 시간 간격으로 알림

- 컴퓨터의 리셋 버튼 누르기

- USB 메모리 부착 혹은 해제

 

인터럽트 발생 및 처리 과정

- IDTR (Interrupt Descriptor Table Register) : 인터럽트 벡터 테이블의 시작 주소와 크기를 가진 CPU 안에 있는 레지스터

인터럽트 서비스 루틴과 운영체제

■ 인터럽트 서비스 루틴

- Interrupt Service Routine, ISR, 인터럽트 핸들러

- 위치 : 디바이스 드라이버나 커널 코드, 임베디드 컴퓨터 ROM

 

■ 디바이스 드라이버와 인터럽트 서비스 루틴, 그리고 커널

 

인터럽트는 다중프로그래밍 실현의 키

■ 다중프로그래밍 리뷰

- 여러 프로세스를 동시에 실행

- 한 프로세스가 입출력을 시행하면 다른 프로세스로 교체 실행

- 입출력이 완료될 때, 장치로부터 입출력 완료 통보를 받는 방법 필요 -> 그것이 바로 인터럽트

    - if 인터럽트X then CPU는 입출력 완료를 계속 검사하는 폴링을 실행해야함 -> 매우 비효율적

■ 만약 인터럽트가 없다면?

- 다중프로그래밍 운영체제의 구현은 사실상 거의 불가능

■ 인터럽트의 효과

- 입출력 장치와 CPU가 동시에 각자의 작업 실행

    - 입출력 장치는 지시받은 입출력 진행, CPU는 다른 프로그램 실행

- 컴퓨터 시스템이 효율적으로 작동

    - CPU 활용률이 높아지고, 시스템 처리율 향상