My yesterday's beautiful.

데이터를 서로 주고 받아 야만 하거나( interactive, 대화형, 쌍방향의 ) 느린 디바이스 또는
단위 시간당 비교적 작은 양의 데이터 전송만 필요한 경우 buffered I/O 전송 방법을 사용 할 수 있다.
대화형 전송의 경우 physical memory를 사용하게 되므로 전송 속도가 향상 된다.
그 이유는 메모리 관리자( memory manager )가 매번 전송이 있을 때 마다 사용되는 모든 메모리를
고정 할( lock down ) 필요가 없기 때문이다.
- direct I/O에서는 매 전송마다 메모리를 lock down 하고 있기 때문에
  작은 데이터를 위해 매번 메모리를 lock down하는 절차를 없애기 때문에 속도가 빨라지는 것이다.보통 비디오, 키보드, 마우스, serial, parallel 드라이버가 buffered I/O 전송 방법을 요청한다.

I/O manager는 I/O 명령이 다음과 같이 buffered I/O 전송 방법을 사용하도록 하고있다.

• IRP_MJ_READ와 MJ_WRITE 요청을 위해 DEVICE_OBJECT 구조체의 Flags 값을 DO_BUFFERD_IO 값으로 한다.
• IRP_MJ_DEVICE_CONTROL 와 IRP_MJ_INTERNAL_DEVICE_CONTROL 요청을 위해서 IOCTL code의 Method에 TransferType중의 하나인 METHOD_BUFFER 값을 채운다.

다음의 그림에서는 I/O manager가 buffered I/O 전송 방법을 사용하여 어떻게 IRP_MJ_READ 요청을 다루는지 보여준다.

Using buffered I/O

User 레벨의 버퍼를 위한 Buffered I/O

위 그림은 드라이버가 읽기 요청을 위한 IRP안의 SystemBuffer의 포인터를 어떻게 사용 하는지 보여준다.

The figure shows an overview of how drivers can use the SystemBuffer pointer in the IRP to transfer data for a read request, when a driver has _ORed the device object's Flags with DO_BUFFERED_IO:

1. user-space virtual address의 어떤 범위는 현재 thread의 버퍼를 나타내고 그 버퍼의 내용은 page-based physical address의 범위안 어딘가에 저장 될 것이다.( 가려진 Physical Memory( Pages )의 어두운 부분이 application에서 사용하는 버퍼가 physical memory에서는 그림 처럼 저장 되어 있다는 것을 나타낸다. )
2. I/O manager는 어떤 thread가 전달하는 user-space virtual address의 버퍼인지를 위해 현재 스레드의 읽기 요청을 처리한다.
3. I/O manager는 접근 용이성을 위해 user-supplied 버퍼를검사하고 ExallocatePoolWithTag를 호출하여 user-supplied buffer의 크기 만큼 상주 시스템 버퍼( resident system-space buffer, SystemBuffer )를 생성한다.
4. I/O manager는 드라이버로 전달 될 IRP에게 새롭게 할당된 SystemBuffer를 접근 할 수 있도록 해준다. 만약, 이 것이 쓰기 요청을 나타내는 그림이였다면, I/O manager는 IRP를 드라이버로 보내기전에 user 버퍼에서 system 버퍼로 데이터를 복사 했을 것이다.
5. 전단계에서 보여준 읽기 요청을 위해서 드라이버는 system-space 버퍼로 부터 디바이스로 데이타를 읽어온다. 이 때 읽기 요청에 대해 충분한 작업을 했다면, 드라이버는 IRP와 함께 IoCompleteRequest를 호출한다.
6. 원래의 thread가 한 번더 활성화 되면, I/O manager는 system buffer 안의 read-in data를 user buffer로 복사하고 ExFreePool도 호출하여 system buffer를 해제한다.

I/O manager가 드라이버를 위해 system-buffer를 생성한 후, user-mode thread 요청은 옮겨 비워질 수 있고( 있던 곳의 데이터가 다른 곳으로 옮겨지고 있던 자리는 비워지는 것) 그 물리적인 메모리는 다른 thread( 어쩌면 다른 process에 속한 thread 일 수도 있다 )를 위해 재사용 될 수 있다. 아무튼 IRP안의 system-space virtual address 범위는 드라이버가 IRP와 함께 IoCompleteRequest 호출 할 때 까지 유효 할 것이다.

한 순간 많은 양의 데이터를 전송하는 드라이버의 경우, 특히 multipage 전송( 전체 데이터를 한 번에 보내는 것이 아니고 나누어서 보내는 전송을 말하는 것 같음 )은 buffered I/O를 사용하려고 시도 하지 말라. 시스템이 돌아가면서 nonpaged pool은 조각 나기 때문에 결국은 I/O manager가 드라이버로 보낼 IRP안에 들어갈 크고 연속된 메모리를 할당 할 수 없게 될 것이다.

전형적으로, IRP_MJ_DEVICE_CONTROL request 같은 IRP들은 direct I/O를 사용 한다고 해도 드라이버는 buffered I/O를 사용한다.

Typically, a driver uses buffered I/O for some types of IRPs, such as IRP_MJ_DEVICE_CONTROL requests, even if it also uses direct I/O. Drivers that use direct I/O typically only do so for IRP_MJ_READ and IRP_MJ_WRITE requests, and possibly driver-defined IRP_MJ_INTERNAL_DEVICE_CONTROL requests that require large data transfers.

Every IRP_MJ_DEVICE_CONTROL and IRP_MJ_INTERNAL_DEVICE_CONTROL request includes an I/O control code. If the I/O control code indicates that the IRP must be supported by using buffered I/O, the I/O manager uses a single system buffer to represent the user application's input and output buffers. A driver that supports such an I/O control code must read input data (if any) from the buffer and then supply output data (if any) by overwriting the input data. For more information, see Defining I/O Control Codes.