하이 올, 오늘은 새로운 챕터를 공부해 볼 예정이예요. (뭐, 결국엔 어제처럼 좌절할 예정이지만요.. 쳇 - _-);
WDF는 UMDF와 KMDF로 구성되어 있어여, UMDF는 이름처럼 UserMode 이고 KMDF는 역시나 예상대로 KernelMode 예요. 따라서 어떤 방식으로 구현을 하는게 편하고 빠르고 안전하게 할수 있는지를 알아야 적당히 써먹을수 있을거 같은 생각이 막 들어여. 안그래여? 안그러면 보지마!
WDF가 UMDF와 KMDF로 나뉘어 있긴 하지만, WDF라는 이름을 '뭉뚱그려' 쓴 이유가 있을거 같지 않아여? 그렇져. 사실 WDF의 핵심(공통)사항은 대부분의 드라이버 코드가 귀찮게 PNP나 전원상태 추적과 같은 시스템에 영향을 미치는 루틴을 신경쓰지 않고 디바이스 제어루틴에 집중할수 있도록 해 주는거예요. 즉, UMDF던 KMDF던 PNP나 전원상태 추적을 해 준다는 거예요.
뭐, 사실 뜬소문이긴 한데, WDM에서 걔네(PNP, 전원관리)가 대부분 비슷비슷한 코드로 이루어져 있는데, 그 양이 장난이 아니라고 하더라구요. 한마디로 프로그래머 입장에서 보면 '괜한 삽질'에 해당하는 코드라는거지영. : )
UMDF
UMDF는 USB처럼 프로토콜 기반의 PNP를 지원하는 드라이버 개발을 위한 COM기반의 프로그래밍 모델이래여. 근데, COM이 뭔가여? 먹는건가여? COM은 Common Object Model이라고 하는데. 관련 책을 보면 머리가 뽀개질거 같은 고통이 느껴질거 예여. 그래서 나도 신경 안쓰고 있어여. 근데! ㅋ, 핵심이 뭐냐면 COM모르면 UMDF 개발 못해여 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아 미쳐. 가능하면 나중에 COM도 책을 보고 그대로 배껴 적어 주겠어영. ㅎ .ㅎ
UMDF 콜백 오브젝트
아, 이거 개념은 이해되는데, 세부 설명은 진짜 이해가 불가능하다. (차라리 나에게 샘플을 보여다오!)
간단한 설명은 이렇다. 프레임웍은 기본적으로 모든 이벤트에 디폴트 처리를 제공한다. 그리고 드라이버는 처리해야 할 이벤트에 대한 콜백 오브젝트를 구현하고, 이 오브젝트를 프레임웍에 등록해, 프레임웍의 이벤트 디폴트 처리를 오버라이드 할 수 있단다. (개념 설명은 참 간단해 음 음.. 하지만 세부 설명은.. 한국말로 말하라고! 한국말!)
KMDF
KMDF는 필터, 펑션, 버스 드라이버 개발을 지원하는 커널 모드 프로그래밍 모델이랍니다. (... 필터, 펑션, 버스 말고 또 무슨 드라이버가 존재 하기는 함?)
근데, 그러면 WDM과 뭐가 다름? 이라는 의문이 생기는데, 물론 다른점이 있다. (단지, 이해가 안될뿐이지..-.-)
프레임웍은 재진입 가능한 라이브러리인데, 이녀석이 드라이버 로드시에 드라이버와 결합(이게 merge를 이야기 하는건지 bind를 이야기 하는건지 bridge를 이야기 하는건지 알지를 못하겠다. 근데, merge랑 bind랑 bridge랑 뭔 차이가 있는거냐?)한다고 한다.
KMDF 콜백 함수
드라이버가 프레임웍 오브젝트가 발생시키는 이벤트중 하나를 처리해야 한다면, 드라이버는 콜백 함수를 구현해 프레임웍에 등록해야 한다고 함. (이거 이해안되면, 나보다 이해력 딸리는거임. 알간?)
UMDF 드라이버에서 치명적인 에러
UMDF 드라이버에서 에러가 나면 어떻게 될까? 우리가 알고 있는 일반적인 드라이버들은 모두 커널에서 동작한다. 따라서, 만약 메모리에 잘못된 접근을 한다거나 하면, 공포(스러울리가.. 하도 많이봐서 지겹다)스러운 BSOD를 보게되지만, UMDF는 말 그대로 UserMode 따라서, 프로세스만 종료하게 된다. (프로세스가 이상 종료되었다는 팝업 정도는 뜨겠지 ㅎㅎ;)
KMDF 드라이버에서 치명적인 에러
KMDF, 즉 KernelMode 에서 치명적인 에러가 발생하면 어떻하겠는가? 이건 간단히, 당신 뇌속에서 폭탄이 터졌는데, 당신은 어떻게 되었을까를 생각해 보면 쉽게 추측할 수 있다. ... 답은 '골로 간다' 이다. 모든 프레임웍 벅첵(bugcheck)은 WDF_VIOLATION 코드를 사용하고 4개의 인자를 갖는다고 한다. 난중에 해당 부분까지 읽게되면 그때 또 베껴 적어 보겠다.
우웅. 결론적으로다가 UMDF는 KMDF보다 개발이 편하고(BSOD는 안보잖니, 따라서 에러 날때마다 컴터 리붓할 필욘 없잖니. 아, 한개더, 컴터 한개로도 개발이 가능하다. 디버깅도!!) 시스템 안정성도 향상되고(문제 생기면, 프로세스만 죽는다니까. 커널모드에서 문제생기면?? 시스템 리붓빼고 답이 안나온다능) 보안 위험도 엄써효. 왜냐면 제한된 권한의 로컬 서비스 계정에서만 동작하니까 : ) 한개더. 이건 어쩌면 축복일지도 모르는것이지만, 대부분의 API를 사용 가능하다고 한다능(단, GUI관련 API는 제외). 음, 생각해보니 디버깅도 편하구나. 앞서 적었지만, 컴터 한대로도 디버깅이 가능하다능! 뭐, 그리고 자잘하게는 C+로 개발이 가능하다는것, 속도도 커널모드 드라이버에 비교해서 거의 차이가 없다는것 정도가 되겠다.
그러나! 그럼에도! 커널모드 드라이버에 비교해서 딸리는것도 있어여.
인터럽트 처리가 안되지영 ㅋㅋ, 그리고 조낸 time critical한것은 커널모드에서 처리하는게 더 낳아여. 웅.. 그리고 커널 메모리에 직접 접근하고 싶다면 커널모드 드라이버 빼고 답이 없지영 : )
이게 뭔 공분가여? 이건 뭐.. 베껴 쓰기밖에 아니고.. 난 눈물이 나고, 오늘 술도 먹었고,.. 헛소리만 찍찍 적고 있고...
WDF는 UMDF와 KMDF로 구성되어 있어여, UMDF는 이름처럼 UserMode 이고 KMDF는 역시나 예상대로 KernelMode 예요. 따라서 어떤 방식으로 구현을 하는게 편하고 빠르고 안전하게 할수 있는지를 알아야 적당히 써먹을수 있을거 같은 생각이 막 들어여. 안그래여? 안그러면 보지마!
WDF가 UMDF와 KMDF로 나뉘어 있긴 하지만, WDF라는 이름을 '뭉뚱그려' 쓴 이유가 있을거 같지 않아여? 그렇져. 사실 WDF의 핵심(공통)사항은 대부분의 드라이버 코드가 귀찮게 PNP나 전원상태 추적과 같은 시스템에 영향을 미치는 루틴을 신경쓰지 않고 디바이스 제어루틴에 집중할수 있도록 해 주는거예요. 즉, UMDF던 KMDF던 PNP나 전원상태 추적을 해 준다는 거예요.
뭐, 사실 뜬소문이긴 한데, WDM에서 걔네(PNP, 전원관리)가 대부분 비슷비슷한 코드로 이루어져 있는데, 그 양이 장난이 아니라고 하더라구요. 한마디로 프로그래머 입장에서 보면 '괜한 삽질'에 해당하는 코드라는거지영. : )
UMDF
UMDF는 USB처럼 프로토콜 기반의 PNP를 지원하는 드라이버 개발을 위한 COM기반의 프로그래밍 모델이래여. 근데, COM이 뭔가여? 먹는건가여? COM은 Common Object Model이라고 하는데. 관련 책을 보면 머리가 뽀개질거 같은 고통이 느껴질거 예여. 그래서 나도 신경 안쓰고 있어여. 근데! ㅋ, 핵심이 뭐냐면 COM모르면 UMDF 개발 못해여 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아 미쳐. 가능하면 나중에 COM도 책을 보고 그대로 배껴 적어 주겠어영. ㅎ .ㅎ
UMDF 콜백 오브젝트
아, 이거 개념은 이해되는데, 세부 설명은 진짜 이해가 불가능하다. (차라리 나에게 샘플을 보여다오!)
간단한 설명은 이렇다. 프레임웍은 기본적으로 모든 이벤트에 디폴트 처리를 제공한다. 그리고 드라이버는 처리해야 할 이벤트에 대한 콜백 오브젝트를 구현하고, 이 오브젝트를 프레임웍에 등록해, 프레임웍의 이벤트 디폴트 처리를 오버라이드 할 수 있단다. (개념 설명은 참 간단해 음 음.. 하지만 세부 설명은.. 한국말로 말하라고! 한국말!)
KMDF
KMDF는 필터, 펑션, 버스 드라이버 개발을 지원하는 커널 모드 프로그래밍 모델이랍니다. (... 필터, 펑션, 버스 말고 또 무슨 드라이버가 존재 하기는 함?)
근데, 그러면 WDM과 뭐가 다름? 이라는 의문이 생기는데, 물론 다른점이 있다. (단지, 이해가 안될뿐이지..-.-)
프레임웍은 재진입 가능한 라이브러리인데, 이녀석이 드라이버 로드시에 드라이버와 결합(이게 merge를 이야기 하는건지 bind를 이야기 하는건지 bridge를 이야기 하는건지 알지를 못하겠다. 근데, merge랑 bind랑 bridge랑 뭔 차이가 있는거냐?)한다고 한다.
KMDF 콜백 함수
드라이버가 프레임웍 오브젝트가 발생시키는 이벤트중 하나를 처리해야 한다면, 드라이버는 콜백 함수를 구현해 프레임웍에 등록해야 한다고 함. (이거 이해안되면, 나보다 이해력 딸리는거임. 알간?)
UMDF 드라이버에서 치명적인 에러
UMDF 드라이버에서 에러가 나면 어떻게 될까? 우리가 알고 있는 일반적인 드라이버들은 모두 커널에서 동작한다. 따라서, 만약 메모리에 잘못된 접근을 한다거나 하면, 공포(스러울리가.. 하도 많이봐서 지겹다)스러운 BSOD를 보게되지만, UMDF는 말 그대로 UserMode 따라서, 프로세스만 종료하게 된다. (프로세스가 이상 종료되었다는 팝업 정도는 뜨겠지 ㅎㅎ;)
KMDF 드라이버에서 치명적인 에러
KMDF, 즉 KernelMode 에서 치명적인 에러가 발생하면 어떻하겠는가? 이건 간단히, 당신 뇌속에서 폭탄이 터졌는데, 당신은 어떻게 되었을까를 생각해 보면 쉽게 추측할 수 있다. ... 답은 '골로 간다' 이다. 모든 프레임웍 벅첵(bugcheck)은 WDF_VIOLATION 코드를 사용하고 4개의 인자를 갖는다고 한다. 난중에 해당 부분까지 읽게되면 그때 또 베껴 적어 보겠다.
우웅. 결론적으로다가 UMDF는 KMDF보다 개발이 편하고(BSOD는 안보잖니, 따라서 에러 날때마다 컴터 리붓할 필욘 없잖니. 아, 한개더, 컴터 한개로도 개발이 가능하다. 디버깅도!!) 시스템 안정성도 향상되고(문제 생기면, 프로세스만 죽는다니까. 커널모드에서 문제생기면?? 시스템 리붓빼고 답이 안나온다능) 보안 위험도 엄써효. 왜냐면 제한된 권한의 로컬 서비스 계정에서만 동작하니까 : ) 한개더. 이건 어쩌면 축복일지도 모르는것이지만, 대부분의 API를 사용 가능하다고 한다능(단, GUI관련 API는 제외). 음, 생각해보니 디버깅도 편하구나. 앞서 적었지만, 컴터 한대로도 디버깅이 가능하다능! 뭐, 그리고 자잘하게는 C+로 개발이 가능하다는것, 속도도 커널모드 드라이버에 비교해서 거의 차이가 없다는것 정도가 되겠다.
그러나! 그럼에도! 커널모드 드라이버에 비교해서 딸리는것도 있어여.
인터럽트 처리가 안되지영 ㅋㅋ, 그리고 조낸 time critical한것은 커널모드에서 처리하는게 더 낳아여. 웅.. 그리고 커널 메모리에 직접 접근하고 싶다면 커널모드 드라이버 빼고 답이 없지영 : )
이게 뭔 공분가여? 이건 뭐.. 베껴 쓰기밖에 아니고.. 난 눈물이 나고, 오늘 술도 먹었고,.. 헛소리만 찍찍 적고 있고...
덧글