사이트 주소는 www.insidekernel.net 입니다. 참고로 이 사이트 주인장 레벨이 초고수 이십니다. ^^
첫번째 순서로 아키텍쳐나 WDF 드라이버를 실제로 제작해보기에 앞서 WDF가 무엇인지 간략히 살펴보는 시간을 갖도록 합니다. 참고로 이 글은 whitepaper 중 ‘WDF Introduction’이란 문서를 번역한 것입니다. 인터넷의 다른 WDF 소개글과 중복되는 내용이 있으나, 이후의 강좌글에 대한 이해와 일관성을 위하여 우선적으로 첫번째 강좌글로서 소개합니다.
현재의 기술 - WDM 이란?
윈도우는 현재 디바이스 드라이버 개발을 위해 ‘WDM(Windows Driver Model)’이라는 모델을 지원하고 있습니다. 그리고 작성하려는 특정한 디바이스 종류에 따라서 device-class specific한 드라이버 모델을 따로 가지고 있기도 합니다. 구체적으로 나열하자면, WDM은 비동기 I/O(asynchronous I/O), 드라이버 레이어링, plug and play, power management, WMI 같은 것들을 포함하고 있습니다.
device-class specific driver model은 크게 두 종류로 구분할 수 있습니다.
클래스 드라이버 = 포트 드라이버(MS가 제작) + 미니포트 드라이버(하드웨어 벤더가 제작)
- 포트 드라이버는 디바이스 클래스에 필요한 많은 작업을 함.
미니포트 드라이버는 드라이버 specific한 것을 지원.
예를 들어보자면, MS가 제공하는 SCSI 포트 드라이버는 SCSI 디바이스를 위한 기본적인 요구사항들을 처리하고, SCSI 미니포트 드라이버는 디바이스 specific한 작업들을 지원합니다.
윈도우가 새로운 디바이스 클래스들을 추가로 지원하면서, 미니포트 모델도 늘어났고, 현재 윈도우는 열개가 넘는 미니포트 모델을 지원하고 있습니다.
WDM의 한계
1. WDM 드라이버를 작성하는 것은 로우레벨 작업이고 또한 매우 복잡하다.
예를 들어서, 현재의 WDM 모델에서 드라이버를 작성할 때 plug and play와 power management를 지원하려면 최소한 2000 라인이 필요합니다. 또한 power management, pnp, 동기화, 비동기 i/o 를 쓰기위한 DDI(device driver interface)역시 무척 쓰기가 어렵습니다. 완벽한 pnp 와 power management state 엔진을 구현하기 위해선 최소 100가지 state를 지원해야 합니다.
2. DDI가 구식이다
DDI가 처음 디자인 될 때에는 지금과는 상황이 많이 달랐기 때문에, 현재의 요구사항과는 좀 차이가 있습니다. 몇년전 처음으로 DDI를 디자인 할 때에는, MS는 써드파티 드라이버 개발 업체를 참여시키지 않았다고 합니다. 그래서 DDI는 커널로부터 곧바로 export 되었으며, 오직 퍼포먼스 만을 위해 디자인되었고, 보안이나 사용의 편의성 같은건 고려되지 않았습니다. 그리하여 DDI는 드라이버들에게 운영체제의 핵심적인 데이터 구조들을 곧바로 노출하고, 결과적으로 MS는 이런 구조체들의 변경이 제한될 수 밖에 없었고, 드라이버가 시스템을 크래쉬 시킬 확률도 높아진 것입니다.
또한 Versioning 지원이 없어서, 윈도우의 버전이 달라지면 드라이버도 다른 바이너리를 사용해야 하거나, 가장 오래된 윈도우 버전에서 사용가능한 기능만을 써서 만들어야 했습니다.
3. 미니포트 모델이 너무 많다.
윈도우는 현재 열개 이상의 미니포트 모델을 지원하고 있습니다. 미니포트 모델마다 pnp와 power management를 다루는 방법이 다릅니다. 미니포트 인터페이스는 운영체제에 새로운 기능이 추가될 때라던가, 새로운 하드웨어 기술이 나올때마다 새로 업데이트 되어야 합니다. 결과적으로, 미니포트 인터페이스는 자주 옛날 기술이 됩니다.
4. 멀티펑션 디바이스를 지원하는 작업은 너무 복잡하다.
두가지의 다른 미니포트 모델에 적용되는 멀티펑션 디바이스를 지원하기 위해서, 개발자는 WDM 버스 드라이버와 두개의 미니포트 드라이버 작성이 필요합니다.
5. 현재 드라이버 모델은 커널 레벨에서만 동작해야 한다.
WDM과 미니포트 드라이버 모델은 커널모드에서 실행되고, 커널 모드 드라이버는 운영체제의 일부로 대접받게 되므로, 시스템의 가상 메모리 영역에 접근권한을 가지고 있습니다. 그래서 커널 모드 드라이버에서 에러가 발생하면 바로 시스템을 크래쉬 시키는 BSOD를 겪게 되지요.
오늘날의 많은 디바이스들은 인터럽트나, 엄격하고 긴급한 타이밍 관리나, 하드웨어 레지스터를 직접 건드릴 일도 없습니다. 이런 드라이버들은 유저모드에서 동작해도 충분합니다.
6. 테스트 툴들이 쓰기 어렵다
새로운 정적 분석 툴인 PREfast와 static drive verifier는 드라이버 퀄리티를 아주 크게 향상시킬 수 있습니다. 이런 툴들은 룰집합에 따라 코드를 검사합니다.
차세대 윈도우즈 드라이버 모델의 디자인 목적
1. 드라이버 모델은 심플하고 유연성(flexible)이 있어야 한다
심플하고 플렉서블한 드라이버 모델은 쉽게 빠르게 견고하고 믿을 수 있는 드라이버를 생산하는데 도움을 줍니다.
2. 드라이버 모델은 코어 운영 체제 컴포넌트와 분리되어야만 한다.
드라이버 모델은 운영 체제의 세세한 부분과는 별도로 구분되어 별도의 프레임웍으로 구성되어야 합니다. 이렇게 함으로써 MS는 드라이버와의 호환성에 대한 걱정없이 운영체제를 업데이트 할 수 있을 것이고, 운영 체제의 새 버전이 나와도 드라이버 개발자들이나 하드웨어 벤더들이 이에 영향없이 일을 할 수 있을 것입니다.
3. 드라이버 모델은 일관성이 있어야 한다.
드라이버 모델은 모든 디바이스 클래스 들에 대해서 일관성이 있어야 합니다. 모든 디바이스들이 반드시 지원해야 하는 PnP나 Power Management, 동기화, I/O 큐, 레지스트리 엑세스, DMA 지원같은 운영 체제를 위한 핵심 기능들이 모든 디바이스 종류에 구애받지 않고 일관성 있게 개발자들에게 제공되어야 합니다. 그렇게 되면 개발자가 새로운 디바이스에 대한 드라이버를 작성할 때에도 진입장벽을 낮게 가져갈 수 있을 것입니다.
4. 드라이버 모델은 확장성이 있어야 한다.
5. 드라이버 모델은 유저모드를 지원해야 한다.
유저모드 드라이버는 시스템의 안정성을 크게 높일 것입니다.
6. 드라이버 모델은 고급 레벨의 언어를 지원해야 한다.
객체 지향과 type-safe 를 지원하는 언어로 작성하면 코드 분석 툴에 큰 도움이 됩니다.
WDF (Windows Driver Framework)
WDF는 다음 컴포넌트들을 포함합니다.
- 커널모드 드라이버 프레임웍.
유저모드 드라이버 프레임웍
드라이버 검증 툴
WDF는 객체 지향, 이벤트 드리븐(event-driven) 모델을 제공합니다!
WDF의 Object들은 블럭 쌓기처럼 동작합니다. 드라이버는 이들 object들을 잘 정의된 인터페이스를 통해서 수정합니다.
특정 이벤트들은 지정된 object의 타입에만 영향을 미칠 수 있습니다. 프레임웍은 각 이벤트에 대한 기본 동작을 정의합니다. Device specific 한 행동을 정의하기 위해서, 드라이버는 기본 핸들러를 오버라이딩 하는 콜백 루틴을 포함합니다. (즉, 프레임웍에 의해서 디바이스 드라이버에 필요한 수많은 기본 핸들러들이 기본으로 제공이 되며, 개발자들은 자신에게 필요한 이벤트만 C++에서의 상속과 같이 오버라이딩을 하여 구현하면 됩니다)
MS는 WDM과 NDIS와 같이 기존의 미니포트 모델 드라이버 지원을 계속할 것입니다.
1. 커널 모드 드라이버 프레임웍(Kernel-Mode Driver Framework)
커널모드 드라이버 프레임웍(KMDF)은 커널모드 드라이버를 만드는데 필요한 기본적인 기능인 PnP, Power Management, I/O 큐, DMA, WMI 그리고 synchronization 같은 기본적인 기능들을 구현하고, IEEE 1394, USB 같은 주요 버스들에 대한 지원도 합니다.
커널모드 드라이버 프레임웍은 운영체제 커널의 일부분으로 포함된 것이 아니라, 별도로 제공되는 독립된 라이브러리입니다.
커널모드 드라이버 프레임웍을 사용하면 멀티펑션 디바이스를 지원하는 버스 드라이버를 작성하는 것이 현재의 WDM 모델을 사용해서 하는 것보다 훨씬 간단해집니다. 위와 같은 상황에서 드라이버는 그 자신의 자식 디바이스들을 enum하여 각 자식 디바이스들의 프로퍼티들을 리스트 합니다. 이때 KMDF의 프레임웍은 device object 셋팅, 자식 디바이스들을 위한 드라이버에게 IRP 보내기, 등과 같은 기본적이고 공통된 요구사항들을 대신 처리합니다. 이와 관련된 내용은 KMDF는 샘플 토스터 버스 드라이버를 참고하시면 됩니다.
커널모드 드라이버 프레임웍에서 인터페이스는 미래에도 가능한 한 드라이버의 독립성을 추구하도록 디자인 되었습니다. 만약 드라이버가 크래쉬되면, 운영체제는 시스템을 멈추거나 전체를 크래쉬하지 않고 복구하거나 드라이버에 의해 할당된 리소스들을 클린업 합니다. 이러한 드라이버의 독립성을 구현하기 위해서는 인터페이스가 잘 디자인 되어야 합니다.
그리고 WinUSB, ultrawide 밴드, HD Audio, 그리고 다른 여러 다른 디바이스 타입들이 비스타를 위한 KMDF 드라이버로 계획되어 있습니다.
2. 유저 모드 드라이버 프레임웍 (User-Mode Driver Framework)
유저모드 드라이버 프레임웍(UMDF)은 PnP, Power Management, 비동기 I/O 지원을 포함하는 커널모드 프레임웍 기능의 일부분을 구현하고 있습니다. DMA 수행, 인터럽트 지원, nonpaged 풀 같은 커널모드 리소르를 사용하지 않는 드라이버들이라면 유저모드에서 실행될 수 있습니다.
유저모드 프레임웍을 사용하면 개발자들은 네트워크와 연결된 디바이스들(network-connected devices)을 위한 드라이버와 PMP, 카메라, 셀폰 같은 USB 디바이스들을 위한 드라이버를 만들 수 있습니다. 비록 이들 드라이버들이 유저모드에서 실행되지만, 그것들은 커널모드 PnP 드라이버들과 동일한 방법으로 시스템이 찾고 설치하는 표준 PnP 드라이버입니다.
유저모드 드라이버 프레임웍은 비스타에서 지원될 것입니다. XP에서의 UMDF지원은 정책결정 중입니다.
3. 드라이버 검증 툴들(Driver Verification Tools)
두개의 룰 기반 정적 분석 툴인 PREfast와 Static Driver Verifier(SDV)가 커널모드 드라이버/유저모드 드라이버 프레임웍 모두를 지원할 것입니다.
PREfast는 드라이버가 지켜야만 하는 규칙들을 검사합니다.
PREfast는 드라이버의 코드가 어떻게 어떤 함수들을 호출하는지를 룰에 따라 분석합니다. 예를 들어서, 함수A가 스핀락을 얻고나서 PASSIVE_LEVEL에서 실행되어야만 하는 Z 함수를 호출하려고 했을때, PREfast는 스핀락을 얻어서 IRQL이 DISPATCH_LEVEL로 올라갔다고 이 에러를 표시해줄겁니다. 그러나, 만약 함수 A가 스핀락을 얻고, DISPATCH_LEVEL에서 호출되도 되는 함수 M을 호출했는데 함수 M이 함수 Z를 호출하려고 했다면, PREfast는 이런 에러는 못 잡아냅니다. PREfast는 Windows Server 2003 SP1 DDK에서 얻을 수 있고, 이후 버전은 WHDC 웹사이트에 올아올 겁니다.
SDV
SDV는 룰 기반의 툴로서, 윈도우 내부와 어떻게 드라이버가 운영 체제 내부의 인터페이스들을 사용해야 하는지에 대해 지식을 가지고 있습니다. DriverEntry를 호출하고 차례로 AddDevice를 호출하는 것처럼 운영체제의 호출을 에뮬레이팅 합니다.
출처 : www.insidekernel.net
