1. Overview
- 컴퓨터의 두가지 주요 작업은 연산처리작업(processing)과 입출력 작업(I/O)이다.
- 입출력 장치는 갈수록 다양해지지만, 관련 인터페이스는 점점 표준화 되어 가고 있다.
- Device Driver(SW)는 모든 하드웨어를 일관된 인터페이스로 표현해 주며 이러한 인터페이스를 그보다 상위 층인 커널의 입출력 서브 시스템에게 제공해준다.
2. I/O Hardware
- 다양한 I/O Device들도 Port라고 불리는 연결점을 통해 컴퓨터에 접속되고 접속하는 선들을 하나 이상의 장치들이 공동으로 사용하면 그것을 Bus라고 부른다.
- Bus란 회선의 집합으로써 이를 통해 어떻게 해야 메세지들을 주고 받을 수 있는지를 정한 프로토콜까지 포함한다.
- Device Controller(HW)는 포트나 버스나 입출력 장치들을 제어하는 전자 회로의 집합체이다.
- Device Driver는 다양한 하드웨어를 일관된 인터페이스로 표현해 커널의 Device Controller에게 Device간의 차이를 숨겨준다.
- 컴퓨터는 (Device Controller의) 레지스터를 이용해 입출력 관련 명령을 전달한다.
- 입출력 명령을 해당 장치에 맞는 Bus회선을 통해 입출력 포트 주소와 장치 레지스터간에 비트 읽고 쓰기를 통한 통신
- Device Controller의 레지스터를 프로세스가 사용하는 메모리 주소 공간으로 mapping → Memory Mapped I/O 방식
- I/O Mapped I/O 방식과 Memory Mapped I/O의 차이
A. Polling(Busy-Waiting)
- Device Controller의 레지스터는 크게 상태, 명령, 데이터 레지스터로 구성되어 있다.
- 상태 레지스터는 하드웨어 장치의 현재 상태를 읽을 수 있는 레지스터이다.
- 명령 레지스터는 하드웨어 장치가 특정 동작을 하도록 요청할 때 쓰는 레지스터이다.
- 데이터 레지스터는 하드웨어 장치에 데이터를 보내거나 받거나 할 때 사용한다.
- OS 와 Device간의 Protocol - polling
- Device Controller는 자신의 상태를 상태 레지스터에 기록한다.
- 작업하느라 바쁠때는 busybit를 설정하고 준비가 되었을 경우에는 busybit를 소거한다.
- 호스트는 busybit가 사라질 때까지 반복적으로 상태 비트를 확인한다.
B. Interrupt
- 호스트가 Polling을 하여 장치 상태를 계속 물어보는 것보다, 장치가 준비 되었을 때 알려주는 것이 더욱 효율적이다.
- CPU와 Device들을 연결하는 Bus에는 Interrupt-request line이 따로 있는데 Device Controller는 이 request line으로 interrupt요청을 보낸다.
- 그러면 CPU는 인터럽트 상황을 알아차리고 Interrupt Service Routine을 실행한다.
- ISR루틴 실행
- CPU의 각종 레지스터나, Program counter등을 저장하여 인터럽트 요청 수행 후 다시 이전 상태로 돌아갈 수 있게 한다.
- 인터럽트 요청은 주로 ‘주소’도 남기는데 이 주소와 인터럽트 벡터를(여러가지 요청에 대한 Interrupt handler들의 메모리 주소를 가진다)사용하여 인터럽트에 대해 적절한 Interrupt Handler를 찾아 요청을 수행하게 한다.
- 인터럽트 요청에 대한 수행 종료 후 아까 저장했던 정보들을 불러와 CPU의 상태를 복구한다.
- 인터럽트의 사용: 예외, 우선순위 설정, 소프트웨어 인터럽트 등등
C. Direct Memory Access(DMA)
- CPU가 데이터의 I/O를 반복적으로 요청하는 것은 낭비이다. 그래서 많은 컴퓨터들은 CPU의 PIO작업중 일부를 DMA라는 특수 프로세서에게 위임한다.
- 호스트는 메모리에 DMA 명령 블록(데이터의 전송할 주소,데이터가 전송받을 주소, 전송할 비트수)를 쓰고 이 명령블록의 주소를 DMA에게 알려주면 DMA는 CPU의 도움을 받지 않고도 직접 자신이 I/O를 수행할 수 있다.
- DMA가 직접 I/O Device들과 입출력을 수행한다는 것은 CPU와 독립적으로 동작하는 것이고, 이 경우 메모리 Bus 사용시 충돌이 일어날 수 있다. 이 경우에는 DMA가 우선된다.
3. Application I/O Interface
- 새롭게 생성되고 추가되는 다양한 I/O Device 들이 생기고 있지만, 추상화와 캡슐화, 계층화와 같은 방법을 사용해 모든 입출력 장치들이 일관된 방법으로 다루어 질수 있는 인터페이스를 구성한다.
- 커널의 입출력 구조
- 장치 드라이버층은 여러 I/O Device 간의 차이를 숨겨서 이들을 표준 인터페이스로 보이도록 해준다.
- 한가지 문제는 운영체제마다 장치 드라이버 인터페이스에 대한 규격이 다르다는 것이다. 그래서 운영체제에 맞게 드라이버를 제공해야한다.
4. I/O models
A. Blocking I/O Vs Non-blocking I/O(호출 하는 함수에 대한 리턴)
- Blocking I/O
- Kernel에 I/O Device 사용에 대한 call을 보내고 작업이 끝날 때까지 기다린다.
- 입출력이 즉시 완료 될 수 없는 경우라면 프로세스는 봉쇄 상태로 들어간다.(실행큐→대기큐)
- Non-blocking I/O
- Kernel에 I/O Device 사용에 대한 call을 보내고 데이터를 가지고 리턴한다.(데이터 없거나, 조금있거나,완료)
- 그리고 Blocking I/O 와 다르게 작업이 끝날 때까지 기다리지 않고 다른 프로세스를 수행한다.
- 다른 작업 수행 중간중간에 kernel에 System call을 보내 작업 완료를 확인함
B. Synchronous Vs Asynchronous(호출 하는 함수의 작업 완료에 대한 관심)
- Non - block I/O 방식은 User가 호출하는 어떤 함수의 완료 여부를 다른 작업 중간중간에 Kernel에게 물어봐야하는 자원 낭비가 있다.
- 여기서 I/O 이벤트 통지에 대해서 그 주체를 나눌 수 있다.
- 호출하는 함수가(User) 호출되는 함수(Kernel)의 작업완료 여부를 물어보는 것(Synchronous)
- 호출되는 함수(Kernel)에 callback을 추가하여 호출되는 함수가(kernel) 작업완료 여부를 알려주는 것(Asynchronous)
- Synchronous
- User에서 어떤 함수를 호출할때, 그 함수의 작업 완료 여부를 반복해서 Kernel에 물어본다
- 어떤 태스크가 순서에 맞춰서 일어나야 하는 것이다. A → B → C 순으로 일어나야하는 것 / 예를 들자면 건물은 1층부터 N층까지 순서에 맞게 지어야 한다.
- 순서에 맞추어 진행되므로 동시에 여러가지 요청을 진행할 수는 없다.
- Asynchronous
- 태스크가 순서에 맞추어 일어나지 않는다. A, B, C에 대한 요청을 하면 그 반환순서가 요청 순서대로 끝나지 않는다. / 건물은 1층부터 순서대로 지어야 하지만, 방 또한 1호부터 n호 까지 순서대로 지을 필요는 없다.
5. Kernel I/O Subsystem
A. I/O Scheduling
- I/O를 실행 할 순서를 결정하는 것이다.
- 시스템의 효율 향상 / 공정한 접근 / 대기시간 줄이기
B. Buffering
- 버퍼링의 이유
- 생산자와 소비자의 속도차이
- 이중 버퍼: 동시에 쓰고/읽는 과정이 일어날경우를 위해
- 데이터 전송 크기가 다른경우의 완충
- 응용 프로그램 입출력의 Sementic: 응용 프로그램이 System call을 하는 시점의 Application Buffer에 담긴 내용이 Kernel Buffer로 복사된다. System call 이후의 Application Buffer 변동은 Kernel Buffer에 반영이 안된다.
C. I/O Protection
- User(Application)은 I/O Device에 대한 입출력 명령을 직접하지 못한다.
- I/O Device에 대한 입출력 명령은 User(Application)의 System call을 통해 Kernel영역으로 진입후 인터럽트 벡터에 기록을 남기며 실행된다. Kernel mode와 User Mode
- Memory mapped I/O의 경우 I/O Device에 대한 입출력 요청을 처리하는 메모리의 주소공간도 보호 되어야 한다.
D. etc
- Cahing, Spooling and Device Reservation, Error Handling…
