WDF를 설명하기에 앞서서 WDM부터 알고넘어가야한다.
WDM을 기반으로 하여 WDF가 구현되는거라고 생각하기에 ㄷㄷㄷ
그럼 차차 설명하기로 하고 ....
http://www.microsoft.com/whdc/driver/wdf/wdf-arch.mspx 여기있는 문서를 참고하였습니다.
WDF는 MS의 차세대 Driver-Development Model입니다.
전 WDM과는 별도의 것이라고 생각했었는데 ...그게 아니더군요..WDM의 단점을 극복하기위해 나온 프레임워크라고 해야할것입니다.
번역하면서 느낀건데 몬소린지 모르겠더군요 ....
일단 문서를 보시면 소개부터 좔좔.....모라고 쓰여있는데....나중에 시간나면 올리도록하고
제가 생각하기에 중요하다고 생각되는부분만 다루겠습니다.
WDM은 심각한 제한을 가지고있는데 WDM드라이버는 수천라인의 코드를 가지고있습니다. 이것은 드라이버가 지원해야하는 공통의 특징을 구현하는데 WDM 드라이버는 그 OS커널에서 직접적으로 나오는 디바이스 드라이버 인터페이스(DDIs)를 사용합니다. 그러나 이 DDIs는 오류가 존재하며 이 오류로 인하여 시스템이 망가질수있기때문에 WDF가 나오게 되었습니다.
KMDF-커널 모드 드라이버 프래임워크를 나타내는 말이며
UMDF-유져 모드 드라이버 프래임워크를 나타내는 말입니다.
일단 오브젝트모델이라는것이있는데 이부분은 아직 이해가 안되서 나중에하고
I/O 모델이있습니다. 여기서는 I/ORequest Flow가 나오는데 말그대로 받아들이시면됩니다.
1. IRP dispatcher은 IRP를 점검하고 그것을 I/O package로 보냅니다.
2. I/O package는 WDF request 오브젝트를 만들고 IRP를 나타냅니다. WDF request object를 대기열에 추가하고 현재의 전원상태를 검사합니다.
3. 장치는 low-power에서 있기때문에 I/O package는 read operation을 수행할수있도록 Plug and play/power package를 호출합니다.
4. Plug and Play/power manager package는 defulat 조치를 취하고 driver에 의해 구현된 적절한 전원 관리 callbacks를 부름으로써 작업상태에 대한 장치를 return시켜 줍니다.
5. 그 장치가 성공적으로 작업상태에 들어왔을때, 프래임워크은 그 드라이버에 read 요구를 신속히 처리합니다.
6. 드라이버가 일을 신속히 처리했다면 , 드라이버는 요구를 얻기위해 대기열의 매소드를 호출합니다.
7. 드라이버가 요구를 만족시킬 수도 있다면, 이대로 동작할수있고 할 수 없다면, I/O 타겟에 대한 요구를 보냅니다.
으아 피곤하네요 ㅠㅠ
많은 양은 아니지만 시간날때 KMDF,UMDF의 프래임워크에대해 설명하도록하겠습니다. ㅠㅠ