I/O #2

I/O sw layers

Goals

1. 장치 독립성
2. 일정한 이름(open, read, write, close, a와b는 서로 다른 장치일 때, a.write, b.write 등..)
3. 에러 핸들링
4. 동기 vs 비동기
5. 버퍼링
6. 여러 개 디바이스에 공유 vs 전용(dedicated) 디바이스
   

Device Drivers(디바이스마다 다른 Device Drivers가 존재한다.)

1. 각 I/O 디바이스를 제어하기 위해 Device-specific code(커널에서 같이 동작)가 담겨져 있다.
2. device-independent I/O sw와 interrupt handlers와의 상호작용을 해야 한다.
3. 잘 정의된 모델 그리고 표준 인터페이스에 따라서 만들어져야 한다.(OS와 하드웨어가 잘 맞도록)
4. DD 구현 방식
   -> statically linked with 커널
   -> 부팅할 때 선택적으로 DD를 로딩할 수 있다.
   -> 시스템 리눅스 커널이 실행하면서 DD요청이 들어오면 dynamically 로딩이 가능하다.(ex)USB)(요즘 많이 사용하는 방식)

문제점

1. DD가 충분히 안정적인 코드가 아니라면 전체 시스템에 문제를 일으킨다. 한 번 문제가 생기면 커널이 망가지는 것이라 완전히 시스템이 다운되는 상황이 생긴다.
   -> 주식거래, e-commerce, 버스 안내 시스템, atm 등 임베디드 시스템에서 문제가 생기면 안된다. 만약 DD가 커널 영역을 침범해서 동작하게 되면 커널을 망가뜨릴 수 있다.
   -> OS제작 회사에서 DD를 만드는 것이 아니라 HW제작 회사에서 DD를 만드므로 커널 영역을 잘못건드리는 상황이 발생하여 문제가 생길 수 있다.
2. DD extension이 계속하여 증가하고 있다.
   -> linux 커널 코드의 70%는 DD다.
   -> OS제작 회사보다는 덜 숙련된 개발자에 의해 만들어질수도 있다.
3. 블루 스크린이 생기는 이유
   -> window XP crashes의 85%는 DD의 잘못이다.
   -> 리눅스 커널에 있는 것보다 DD의 버그가 7배 더 많다.

Device-Independent I/O SW

바로 밑에 있는 DD와 상호작용하는 SW이다.(커널을 개발하는 회사에서 만든다.)
1. Unix에서는 divice를 특별한 파일 형태로 관리한다. 즉, 파일을 다루는 open, read, write, close, ioctl 등 시스템 콜들을 통해서 이 디바이스를 다룰 수 있다는 말이다.
-> 파일 이름이 각 디바이스에 맵핑되도록 한다.

2. Major device number는 특정한 driver를 의미한다.
   -> minor device number는 parellel port에서 각 디바이스를 구분하는 번호이다. 같은 디바이스지만 partition별로 다른 번호를 부여한다.

3. 일반적인 protection rule을 file에서 쓰는 것과 함께 쓸 수 있다는 장점이 있다.(read/write 등 file interface를 통해 protection관리를 할 수 있다. 통일되고 일관된 방식으로 디바이스를 다룰 수 있다.)
   

4. error reporting(error handling)
   -> 에러에 대해서 사용자에게 report해줘야 한다.
   -> 적절한 driver에 의해 handle되어야 한다.
   -> programming errors vs 실제 I/O errors

5. handling errors
   -> 반드시 에러 코드와 함께 시스템 콜을 리턴해줘야 한다.
   -> 몇 번 정도 다시 시도할 수 있다.
   -> 에러를 무시할 수 있다.
   -> 프로세스를 죽여야 할 수도 있다.
   -> 시스템을 다운해야 할 수도 있다.

User-Space I/O SW

1. 라이브러리 형태로 제공된다.
   -> C에서 표준 I/O 라이브러리(fopen, open)
2. 라이브러리는 다양하게 제공된다.(fgets, fscanf)
3. 자신만의 라이브러리를 만들 수 있다.(myopen, myfgets)