각각의 device들은 device node들로 표현되어지고, 각 device node는 device stack을 갖는다.
보다 자세한 정보는 "Device nodes and device stacks"을 참조하라.
device로 읽기,쓰기 혹은 제어의 요청을 보내기위하여 I/O manager는 장치를 위한 device node를 찾는다 그리고 IRP를 그 Node의 device stack에 낸다.
때론 하나 이상의 device stack이 I/O request를 처리하는데에 관여되기도 한다.
Device stack의 수와 관계없이 I/O요청과 연관된 driver들은 모두 요청에 대한 driver stack이라 부른다.(발번역 ㅠㅠ)
우리는 driver stack이란 용어를 특정 technology를 위한 driver의 계층화된(Layered)잡합들을 가리킬때도 사용한다.
몇몇 device stack이 처리하는 I/O request
어떤 경우, 하나 이상의 device stack은 IRP를 처리하는데에 관여된다. 아래의 그림은 4개의 device stack이 하나의 IRP를 처리하는데 관여되는 경우를 보여준다.
자~ 아래에 어떻게 IRP가 처리 되는지 그림에 표시된 번호별로 설명한다.
1. IRP는 My USB Storage Device node를 위한 device stack에 있는 function driver인 Disk.sys에 의해 생성된다.
Disk.sys는 IRP를 drvice stack의 아래쪽인 Usbstor.sys에 전달 한다.
2. Usbstor.sys는 My USE Storage Device node의 PDO driver이고 USB Mass Storage Device node의 FDO임을 기억하자.
여기에서 IRP가 (PDO, Usbstor.sys)의 것인지 (FDO Usbstor.sys)의 것인지 결정하는것인 중요하지 않다. IRP는 dirver(Usbstor.sys)의 것이고 이 driver는 PDF와 FDO 양쪽다 접근(access)이 가능하다.
3. Usbstor.sys가 IRP처리를 마쳤을때, IRP는 Usbhub.sys로 전해진다.
USBhub.sys는 USB Mass Storage Deivce node의 PDO driver이며 또한 USB Root Hub node의 FDO driver이다. IRP가 PDO에 있는지 FDO에 있는지는 중요하지 않다. IRP는 driver(Usbhub.sys)에 있고 이 driver는 PDO와 FDO 양쪽 모두 접근이 가능하다.
4. Usbhub.sys가 IRP의 처리를 마쳤을때, IRP는 (Usbuhci.sys, Usbport.sys)pair으로 전달된다.
Usbuhci.sys는 miniport driver이고 Usbposrt.sys는 port driver이다. 이 pair(miniport, port)는 한나의 driver역학을 한다. 이경우, miniport dirver와 port driver 모두 Micro$oft가 작성한 것이다.
(pair-Usbuhci.sys, Usbport.sys)쌍은 USB Root Hub node의 PDO dirver이며 동시에 USB Host Controller node의 FDO driver이다.
(pair-Usbuhci.sys, Usbport.sys)쌍은 Host controller H/W와 통신을 하고 그다음 실제 물리적 USB storage device와 통신을 한다.
I/O request를 위한 driver stack
위 그림에서 I/O request에 참여한 4개의 driver의 순서를 고려하라.
우린 device node와 각각의 device stack이 아닌 driver들에 초점을 둔 순서에 관점을 얻을 수 있다.
아래의 그림은 위로부터 아래에 이르는 순서로 driver를 보여준다.
Disk.sys는 하나의 device object에 연결됨을 보여주지만, 다른 3개의 드라이버는 2개의 device object들과 연결됨을 보여준다.
I/O 요청에 관여된 driver들의 순서들은 driver stack for I/O request라 부른다.
I/O 요청에 관한 driver stack을 설명하려면, 우리는 요청에 참여한 순서대로 위로부터 아래로 driver들을 그린다.
Driver stack for I/O Request은 device node를 위한 device stack과는 매우 다르다는 것을 알 수 있다. 또한 The driver stack for an I/O request는 device tree의 한지점에 남아 있지 않음을 알 수 있다.
Technology driver stacks
일단 앞서본 그림중에 Driver stack for the I/O request를 기억하자. 만약 우리가 위의 그램에서 driver에 익숙한 이름을 지어주고 약간의 약간의 변경을 해준다만. 우리는 Windows Driver Kit(WDK)문서에서 볼수 있었던 익순간 블록다이어그램을 얻을 수 있을 것이다.
이 그림에서 driver stack은 3부분으로 나뉘어져 있다. 우린 각 부분을 특정 technology나 O/S의 일부분 혹은 특정 요소에 대임된다고 생각 할 수 있다.
예를 들어, 우리는 driver stack의 제일 쥐에 있는 첫 부분이 Volume manager에 속한다고 말할 수 있고, 두번째 부분을 O/S의 저장장치(요소)에 속한다고 말할 수 있다. 그리고 세번째 부분을 O/S의 핵심 USB부분에 속한다고 말할 수있다.
세번째 영역에 있는 driver들을 고려해보자. 이 driver들은 다양한 USB 요청들과 USB H/W를 처리하기위해 Micro$oft가 제공하는 핵심 USB driver 집합의 일부분이다.
아래의 그림은 전체 USB core 블럭 다이어그램의 모양세를 보여준다.
위 그림은 특정 기술에 대한 모든 driver들을 보여주거나 O/S의 일부분 혹은 특정 구성요소를 보여주는 a technology driver stack라 불리는 블럭 다이어 그렘이다.
일반적으로, technology driver stacks은 USB Core Driver Stack, Storage Stack, 1394 Driver Stack 그리고 Audio Driver Stack과 같은 이름이 붙여진다.
Note : 이 주제에서 USB Core block diagram은 USB 1,0 및 2,0에 대한 technology driver stacks을 설명하는 여러 방법중 하나를 보여준다.
the USB 1.0, 2.0, and 3.0 driver stack의 공식적인(실제) 다이어그램은 "USB Driver Stack Architecture"를 참조하라.
댓글 없음:
댓글 쓰기