[OS] 시스템콜과 I/O인터럽트

OS 구성요소

시스템콜과 시스템 프로그램은 OS의 2가지 핵심적인 구성 요소

 

시스템콜 탄생 배경

• OS의 목적은 유저가 컴퓨터 자원(하드웨어)를 효율적으로 사용할 수 있도록 도와주는 것
• 해당 목적을 위해 유저 프로그램은 자원(하드웨아)을 사용하고 싶을때 반드시 OS(=Kernels)에 요청을 해야함 (유저/하드웨어 분리)
• 따라서, OS에서 유저에게 자원들을 사용할 수 있도록 해주는 인터페이스(함수)를 구현
  • 해당 인터페이스를 시스템 콜이라고 함

 

 

시스템콜 개념

• 정의: 사용자(프로세스)가 컴퓨터 자원(하드웨어)의 기능을 사용할 수 있도록 해주는 API
• 특징: 시스템콜을 주로 고급 프로그래밍 언어(C, C++)로 작성되며 때때로 어셈블리 언어를 사용

 

파라미터

OS의 서비스를 사용하기 위해 필요한 정보를 파라미터로 전달을 해야함

• 해당 파라미터 정보를 CPU 레지스터나 MM에 저장
• 어디에 저장되어 있는 시스템 콜을 호출할때 해당 정보를 가져와 파라미터로 전달

시스템콜 구현

• 시스템콜 번호 할당: OS가 각 시스템 콜에 고유 번호를 할당
• 시스템콜 인터페이스: 시스템콜 요청을 적절히 커널로 전달
• 인덱싱된 테이블 관리: 고유 번호를 활용한 인덱싱된 테이블을 통해, 각 시스템콜 프로세스의 시작 주소를 저장 

예시: read() 시스템콜 처리 과정

1. 사용자 프로세스에서 시스템콜 요청: 파일을 읽기 위해 read() 시스템콜 요청
   
   • 이때, 필요한 파라미터 정보를 함께 전달
2. 시스템콜 번호로 변경: OS가 read() 시스템콜에 해당하는 고유 번호(예: 3번)로 변경  
3. 인덱싱된 테이블 처리: 시스템콜 인터페이스에서 받은 고유 번호를 통해 테이블에서 해당 번호의 시스템콜을 찾음
   • 3번에 해당하는 read() 시스템콜 시작 주소를 찾음
4. 시스템콜 실행: 커널은 테이블에서 찾은 시작 주소를 사용하여 read() 시스템콜 실행
5. 결과 반환: read() 작업이 완료되면, 커널을 실행 결과와 상태 정보를 사용자 프로세스에 반환

 

유저 모드 vs 커널 모드

핵심: 유저 모드일때, 하드웨어를 건들이면 안되도록 하기 위해 모드를 나눈 것

• 유저 모드: CPU가 유저 프로세스를 실행하고 있는 모드
• 커널 모드: CPU가 OS(커널) 프로세스를 실행하고 있는 모드

 

사용자 관점(추상화)

• 사용자(프로그래머) 관점에서는 시스템 콜 내부 구현이 어떻게 되어있는지 알 필요가 없음
• 단지 API 문법과 규칙을 알고, 무엇을 할 것인지만 이해하면 됨

 

 

시스템콜의 종류

시스템콜은 다음과 같이 다양한 서비스를 제공

• 프로세스 및 작업 조작: 로드, 실행, 종료, 중단 등
• 파일 조작: 파일 생성 및 삭제, 열기 및 닫기, 읽기, 쓰기 및 재배치
• 장치 조작: 장치 요청 및 해제, 읽기, 쓰기 및 재배치
• 정보 유지 관리: 시간 및 날짜 설정, 시스템 데이터 설정, 프로세스, 파일 및 장치 속성 설정
• 통신: 통신 연결 생성 및 삭제, 메시지 전송 및 수신, 상태 정보 전송

 

 

시스템 프로그램

1. 시스템 콜(System Calls): 운영 체제의 핵심 기능에 접근하기 위해 사용자 프로그램이 운영 체제 커널에 요청을 전달하는 저수준의 인터페이스입니다. 
2. 시스템 프로그램(System Programs):
   • 시스템 콜을 기반으로 구축된, 사용자에게 보다 높은 수준의 인터페이스를 제공하는 프로그램들입니다.
   • 시스템 프로그램은 시스템 콜을 사용하여 구현되며, 사용자가 운영 체제의 기능을 보다 쉽고 효율적으로 사용할 수 있게 해줍니다.

 

 

I/O

• 정의: CPU가 외부 장치에 접근하여 read/write작업을 하는 것을 의미
• 특징: 외부 장치 접근 시간이 매우 느림 -> 이것을 cpu가 처리하면 매우 비효율적
• I/O 작업을 처리하는 3가지 방법
  1. CPU가 직접 IO 작업을 진행하는 방법
     
     • 단순하지만, 매우 비효율적인 방법
     • 하지만, OS가 없는 열약한 환경(임베디드)에서는 해당 방법을 이용
  2. 동기 IO 작업: 외부 장치 Controller에게 일을 시키고, CPU는 컨트롤러가 일을 다 할 때까지 기다리기 (그냥 안쓰이는 방법)
  3. 비동기 IO 작업: 외부 장치 Controller에세 IO 작업을 맡기고, 현재 프로세스 A를 대기 상태로 변경하고 다른 프로세스 B를 진행하는 방법
     
     • 보통 3번 방식을 많이 사용
     • 해당 방법을 구현하려면 반드시 OS가 필요

 

 

인터럽트 종류

• HW에서 발생하는 인터럽트: HW에 있는 센서로 인해서 발생하는 인터럽트 신호
• SW에서 발생하는 인터럽트: 프로그램 실행중 발생하는 인터럽트 신호. 예시) divide by zero

 

Device Controller

정의: CPU대신 IO작업을 수행하는 것

CPU와 외부 장치 사이에 있는 컨트롤러( 왼쪽이 CPU 인터페이스, 오른쪽이 디바이스 인터페이스)

 

CPU 인터페이스 구성

CPU는 디바이스 컨트롤러에게 아래 order(=signal, instruction)을 전달하여 I/O작업을 진행하게 함

• Control Line: Read/Write 작업을 결정하는 값
  • 0 = Read, 1 = Write
• Data Line: Read/Write 작업에 사용되는 Data 값
• Address Line: Read/Write 작업에 사용되는 Address 값
• Special Line(Status Register): Read/Write 작업이 끝났는지 알려주는 상태 값 
• I/O Logic: 위 신호들을 가지고 작업을 진행할 Unit

 

비동기 IO 동작 과정 ( = 병렬 진행)

1. CPU가 디바이스 컨트롤러에게 IO작업에 대한 신호(order)를 전달
2. 디바이스 컨트롤러가 아래 작업을 진행
   • IO 작업 진행
   • IO 작업 완료 후, status register 값을 1로 세팅 (인터럽트 발생)
3. CPU가 status register값을 보고 인터럽트 사이클 진행

 

인터럽트 처리 과정

인터럽트 신호(status register)가 CPU에 도착 push(stk_ptr, PC): OS가 메모리 스택에 현재 프로세스 return 주소를 저장 CPU가 어느 디바이스 컨트롤러가 인터럽트를 발생시켰는지 체크 polling 방식: 모든 인터럽트 신호가 동일한 방식 = 어떤 디바이스 컨트롤러에서 보낸 신호인지 구별x CPU가 어느 장치에서 왔는지 확인하는 오버헤드 발생 잘 안쓰는 방식 Vectored interrupt 방식: 모든 인터럽트에 고유의 id가 할당(IRQ n) 디바이스 컨트롤러가 해당 id에 인터럽트 신호를 보냄 그러면 CPU는 어느 디바이스 컨트롤러에서 왔는지 바로 알 수 있음 PC = ISR[i] (xxx, yyy...): 인터럽트 처리 진행 PC = pop(stk_ptr), S[i] = 0: 인터럽트 처리 종료후 다시 원래 프로세스로 돌아옴 & 인터럽트 신호 0으로 초기화

MM 예시 CPU 인터럽트 사이클

 

 

멀티 인터럽트

• 문제: 인터럽트 신호는 당연히 여러개가 발생 가능 -> 그러면 어떤 인터럽트를 처리할지 결정하는 방법이 무엇?
• 해결: 우순순위 큐 사용 - 인터럽트에 우선순위를 부여

 

Preempt-Resume 방법

우선순위 방식의 인터럽트 처리 방법

• Preempt(기존 프로세스 종료): 우선순위가 높은 인터럽트가 발생하면 기존 프로세스를 종료 시킨다
• Resume(기존 프로세스로 복귀): 자기를 Preempt한 프로세스가 종료되어야 다시 기존 프로세스를 다시 실행한다.