[Noenemy]'s microgroove

Driver에서는 이와 유사한 개념으로 특정 IRP(I/O Request Packet)를 처리하는데 관여할 수 있는 여러 driver들이 마치 chain과 같은 형태를 구성하고 있는데 이를 'Driver Stack'이라고 한다. IRP를 처리할 때 필요한 처리 루틴이나 파라미터 등의 정보를 각각의 driver 들은 I/O stack location이라는 구조체에 저장하여 해당 IRP에 append 시켜야 하며, 상위 레벨의 driver는 하위 레벨의 driver에게 IoCallDriver 를 호출해서 IRP를 전달하기 전에 해당 stack location의 정보를 반드시 채워야 한다.

I/O manager는 이러한 Driver Stack을 구현하기 위해서 각 IRP마다 I/O stack location 정보를 저장할 수 있도록 배열을 만든다. 각 driver들은 특정 IRP를 처리하기 전에 IoGetCurrentIrpStackLocation 함수를 호출함으로써 해당 driver가 I/O operation을 수앵하는데 필요한 고유의 I/O stack location 정보를 얻을 수 있다.

다음 그림은 IRP 내에 저장되는 데이터를 도식화한 것이다.

아래 부분에 흰색 블록으로 표현된 것이 하나의 I/O stack location이며, 만약 2개의 driver가 관여하고 있다면 I/O stack location이 하나 더 append 된 형태가 될 것이다.

하나의 I/O Stack Location 정보는 IO_STACK_LOCATION 구조체를 이용해서 정의할 수 있는데, WDK에서 확인할 수 있는 IO_STACK_LOCATION 구조체의 정의는 다음과 같다.

typedef struct _IO_STACK_LOCATION {
  UCHAR  MajorFunction;  // 수행되어야 할 I/O operation 타입
  UCHAR  MinorFunction;  // MajorFunction에 대한 Sub funtion code
  UCHAR  Flags;   // 요청에 대한 플래그 (파일 시스템 드라이버에서 주로 사용됨)
  UCHAR  Control;  //
  union {
        //
        // Parameters for IRP_MJ_CREATE 
        //
        struct {
            PIO_SECURITY_CONTEXT SecurityContext;
            ULONG Options;
            USHORT POINTER_ALIGNMENT FileAttributes;
            USHORT ShareAccess;
            ULONG POINTER_ALIGNMENT EaLength;
        } Create;
        //
        // Parameters for IRP_MJ_READ 
        //
        struct {
            ULONG Length;
            ULONG POINTER_ALIGNMENT Key;
            LARGE_INTEGER ByteOffset;
        } Read;
        /* 이하 생략 */
        /* full list는 http://msdn.microsoft.com/en-us/library/aa491675.aspx 참고 */
  } Parameters;  // MajorFunction과 MinorFunction 수행에 필요한 파라미터

  PDEVICE_OBJECT  DeviceObject;  // IRP를 처리해야하는 target device (DEVICE_OBJECT 구조체 포인터)
  PFILE_OBJECT  FileObject;  // DeviceObject와 관련된 file object (FILE_OBJECT 구조체 포인터 )
 .
} IO_STACK_LOCATION, *PIO_STACK_LOCATION;

WinDbg에서 !irp 명령을 이용하면 다음과 같이 특정 IRP에 관련된 I/O Stack Location 정보를 확인할 수 있다.

0: kd> !irp 0x831f4a00
Irp is active with 8 stacks 5 is current (= 0x831f4b00)
 Mdl = 82b020d8 Thread 8c622118:  Irp stack trace.
     cmd  flg cl Device   File     Completion-Context
 [  0, 0]   0  0 00000000 00000000 00000000-00000000

                        Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000

                        Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000

                        Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000

                        Args: 00000000 00000000 00000000 00000000
>[  3,34]  40 e1 828517a8 00000000 842511e0-00000000 Success Error Cancel pending
               \Driver\disk     partmgr!PmReadWriteCompletion
                        Args: 00007000 00000000 fe084e00 00000004
 [  3, 0]  40 e0 82851450 00000000 842414d4-82956350 Success Error Cancel
               \Driver\PartMgr  volmgr!VmpReadWriteCompletionRoutine
                        Args: 129131bb 000000de fe084e00 00000004
 [  3, 0]   0 e0 82956298 00000000 847eeed0-829e2ba8 Success Error Cancel
               \Driver\volmgr   Ntfs!NtfsMasterIrpSyncCompletionRoutine
                        Args: 00007000 00000000 1bdae400 00000000
 [  3, 0]   0  0 82ac2020 8e879410 00000000-00000000
               \FileSystem\Ntfs
                        Args: 00007000 00000000 00018400 00000000

References 

WDK I/O Stack Locations
http://msdn.microsoft.com/en-us/library/ms795764.aspx

WDK 문서 중에서 I/O Request의 전체 과정을 설명하고 있는 문서가 있어서 이를 번역해 보았습니다. 번역하면서 느낀 것은 역시 기술 문서는 원어 그대로 읽고 이해하는 것이 번역된 문장을 보는 것보다 낫다는 생각이 듭니다. 가능하면 의역을 하려 했는데, 부족한 부분이 있거나 원문 내용을 보시려면 아래 문서를 참고하시기 바랍니다.

Example I/O Request - An overview
http://msdn.microsoft.com/en-us/library/ms795837.aspx

다음 그림은 user mode 어플리케이션에서 특정 file을 open하려고 했을 때 이 요청이 어떻게 커널 레벨에서 file system에 까지 전달된 뒤 그 결과 값으로 handle을 돌려 받는 과정을 설명하고 있습니다.

1. Windows subsystem이 특정 이름의 파일을 open 하기 위해 I/O system service를 호출한다.
2. I/O manager는 해당 파일이 있는지 찾고 해당 file object에 대한 symbolic links를 resolve할 수 있도록 object manager를 호출한다. 또한 subsystem이 해당 file object를 open하는데 필요한 적절한 권한을 가지고 있는지 체크하기 위해 security reference manager를 호출한다.
3. 해당 volume이 아직 마운트되지 않았다면, I/O manager는 open 요청을 잠시 보류하고 해당 해당 file object가 인식될 때까지 여러 file system을 호출한다. 해당 file system이 마운트되면, I/O manager는 open 요청을 다시 재진행한다.
4. I/O manager는 open 요청을 위한 IRP를 초기화하고 메모리를 할당한다. 드라이버 입장에서 'open'은 "create" 요청에 해당한다.
5. I/O manager는 파일 시스템 드라이버를 호출하고 해당 IRP를 전달한다. 파일 시스템 드라이버는 어떠한 명령을 수행해야 하는지 판단하기 위해서 해당 IRP의 I/O stack location에 접근하고, 만약 없다면 해당 IRP의 하위 드라이버의 I/O stack location을 설정한다.
6. 해당 IRP를 처리하고 요청된 I/O 명령을 complete 하려면 I/O manager나 다른 시스템 구성요소에 의해 제공되는 커널모드 루틴을 호출해야 한다.
7. 드라이버는 요청한 명령에 대해 성공했거나 또는 실패한 이유를 I/O status block을 set하고 해당 IRP를 I/O manager에게 리턴한다.
8. I/O manager는 해당 IRP로부터 I/O status 값을 얻고, 이를  subsystem을 통해 최초 호출자에게 상태 값을 리턴할 수 있게 된다.
9. I/O manager는 completed된 IRP를 해제한다.
10. I/O manager는 open 명령이 성공했다면 subsystem에게 해당 file object를 위한 handle을 리턴한다. 만약 실패하였다면 subsystem에게 적절한 status를 리턴한다.

Windows subsystem이 특정 파일에 대한 file object를 open 하는데 성공하면, 그 이후에는 read, write, device I/O 요청과 같은 부수적인 요청에는 리턴된 handle을 이용하게 된다. 이런 요청을 처리하기 위해서 subsystem은 I/O sysem services를 호출하고, I/O manager는 이를 처리할 드라이버에게 IRPs 보냄으로써 이러한 요청을 전달한다.