1 / 80

Device Driver 란 무엇인가 ?

Device Driver 란 무엇인가 ?. 1.Device Driver 의 개요. 2.Windows Device Driver 의 구조. 협우인포테크㈜ www.hyubwoo.com. 3.Embedded NT Device Driver 의 개요. Device Driver 의 개요. 교차 플랫폼 Device Driver 개발 툴. ISA - PCI - USB - PCMCIA Windows 95/98/2000/NT/CE. HW 를 Software 에 연결. DOS 시대 . 더 많은 드라이버를 가질수록 -

tremain
Télécharger la présentation

Device Driver 란 무엇인가 ?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Device Driver란 무엇인가? 1.Device Driver의 개요 2.Windows Device Driver의 구조 협우인포테크㈜ www.hyubwoo.com 3.Embedded NT Device Driver의 개요

  2. Device Driver의 개요

  3. 교차 플랫폼 DeviceDriver개발 툴 ISA - PCI - USB - PCMCIA Windows 95/98/2000/NT/CE

  4. HW를 Software에 연결 DOS 시대... 더 많은 드라이버를 가질수록 - 더 많이 활용할 수 있습니다! 귀하의 App (EXE / DLL) 어플리케이션 BUS 하드웨어

  5. HW를 Software에 연결 요즘... 귀하의 App (EXE / DLL) 어플리케이션 커널 모드 드라이버 (SYS or VxD) 드라이버 하드웨어

  6. 새로운 아키텍쳐의 장점: • 모든 어플리케이션이 하드웨어를 지원할 필요가 없음. • 시스템 혼란 가능성 감소. • 개발 노력 절감. • 어플리케이션 보호(가상 메모리).

  7. Windows 디바이스 드라이버 Windows 95 VxD Windows NT SYS Windows 98 VxD / SYS (WDM) Windows 2000 SYS (WDM)

  8. 2. 계층적인 드라이버 3. Miniport 드라이버 • 단일 • 드라이버 어플리케이션 어플리케이션 어플리케이션 귀하의 드라이버 MINIPORT 귀하의 드라이버 귀하의 드라이버 드라이버 하드웨어 하드웨어 하드웨어 드라이버의 유형

  9. 디바이스 드라이버 작성 시도 • OS Internals 학습 • OS API (DDK, DDI, ..) 학습 • 운영체계간 드라이버가 호환되지 않음. • 커널 레벨 디버깅(WinDBG, WinDK,…) –“블루 스크린 에러” • 테스트되지 않은 하드웨어 취급

  10. 디바이스 드라이버 작성 시도 • 드라이버 안정성 • Microsoft사는 드라이버가 Windows NT를 불안정하게 만드는 주요 원인이라고 주장합니다. • Win NT 및 2000이 항상 호환되는 것은 아닙니다. • WDM은 Windows 98 및 2000간의 모든 호환성 문제를 해결하지는 못합니다. • 어떤 바이오스들은 호환성 문제를 일으키는 것으로 알려져 있습니다.

  11. 예상 개발 시간 드라이버당 1 – 4개월 모든 운영체계 마다...

  12. Windows Device Driver의 구조

  13. Roadmap – Part I • 디바이스 드라이버 플랫폼 호환성 • WDM의 새로운 기능 • Plug and Play 드라이버의 작성 • WDM 드라이버의 Power Management • Windows Management Instrumentation (WMI) • Class/ Minidriver 개요 • Windows 2000와 Windows 98간의 호환성 • WDM 드라이버의 개발 및 테스트에 사용되는 DDK 툴

  14. Windows 디바이스 드라이버아키텍쳐 –플랫폼 지원 Win 3.x Win 95 Win 98 VxD VxD+PnP VxD/PnP + WDM Win 2000 NT 3.x NT 4.x KMD + PnP + WDM KMD KMD VxD = Virtual x Device KMD = Kernel Mode Driver WDM = Windows Driver Model

  15. Windows 디바이스 드라이버아키텍쳐 –핵심적인 차이점 • VxD (Windows 3.x 및 Windows 9x) • Windows 386 core 기반 • KMD (Windows NT 및 Windows 2000) • Windows NT core 기반 • WDM (Windows 98 및 Windows 2000) • Windows NT core 기반 • Plug and Play, Power Management, WMI 추가 • NT 보안은 포함되지 않음 • 파일 시스템, 네트워크, 비디오 지원되지 않음 • API 및 Class Drivers 모두 지원

  16. WDM그 호환성의 신화 • 바이너리 호환으로 의도되었지만, Windows 2000용 WDM은 Windows 98 버전에서 발전된 것입니다. • 호환성 유지가 가능하지만, 개발자들은 주의할 필요가 있습니다.

  17. Windows 2000의 새로운 기능 • Plug and Play • Power Management • WMI • WDM Class Drivers • 기타 (현재 사용하지 않음)

  18. Windows 2000의 새로운 드라이버 기술 © Microsoft Corporation

  19. Windows 2000의 새로운 드라이버 기술 © Microsoft Corporation

  20. 핵심 기능 및 이점 • Plug and Play • 하드웨어를 추가 및 삭제할 때 사용자의 수고를 덜어줌 • 휴대용 컴퓨터 장착 및 분리 지원 • 프로그램적인 하드웨어 리소스 할당 • 자동으로 적절한 해당 드라이버 로드

  21. 핵심 기능 및 이점 • Power Management • 밧데리 수명 연장 • 전원 요구량 절감 • 대기 및 재시작 지원 • Class/Minidriver 아키텍쳐 • 드라이버 계층화 가능 • 디바이스 특정 코드 분리 • Common 컨트롤 인터페이스

  22. 핵심 기능 및 이점 • Windows Management Instrumentation (WMI) WMI은 다음을 가능케 합니다 . . . • 디바이스 관리의 표준화 • 근거리 또는 원격 디바이스 관리 • 드라이버로부터 비동기적인 경고를 수신하는 어플리케이션 • 지능적인 데이터 수집 정책

  23. WDM와 KMD 드라이버의 차이점 요약 • 버스 계산시 하드웨어를 감지하면 시스템이 PnP 드라이버를 설치. • 시스템이 Physical DEVICE_OBJECT (PDO)를 사용하여 구성 및 전원 관리를 위한 디바이스를 설계. • 드라이버가 Function DEVICE_OBJECTS (FDOs)를 PDO에 첨부. • 대부분의 하드웨어 상호작용은 HAL이 아닌 시스템 버스 드라이버에 의해 처리됨. . . . 계속

  24. WDM와 KMD 드라이버의 차이점 요약 • DriverEntry 수정 • DriverUnload 수정 • 다음을 위한 IRP핸들러 • IRP_MJ_PNP • IRP_MJ_POWER • IRP_MJ_SYSTEM_CONTROL • 새로운 AddDevice 함수

  25. ; MyDevice.INF; install information for my device [version]signature="$Windows NT$“Class=ToasterProvider=%MyCorp% [Manufacturer]MyCorp=“MyCorp” [MyCorp]SuperToast=Toast_Inst,TBUS\777f_8888 . . . Class Installer WDM 드라이버 -INF 파일에 의한 설치 • INF 파일을 필요로 하는 PnP 드라이버의 설치 • INF 파일의 구성: • Device Class • 제조업체 • Hardware ID • 드라이버 파일명 • 하드웨어 리소스

  26. Upper Filter Function Driver Lower Filter Bus Driver Hardware WDM 드라이버 -세가지 종류의 드라이버 • Bus Drivers (PDO) • Functional Drivers (FDO) • Filter Drivers

  27. Bus Drivers (PDO) • 버스 계산 • Plug and Play 및 Power Management IRP에 반응 • 필요시 버스를 다중 억세스 • Microsoft가 USB, PCI, SCSI, PnpISA를 위한 드라이버 제공 Upper Filter Function Driver Lower Filter Bus Driver Hardware

  28. FunctionDrivers (FDO) • 디바이스를 위한 메인 드라이버 • 기초 I/O 연산 관리 • 디바이스 지정 전원 요구량 관리 Upper Filter Function Driver Lower Filter Bus Driver Hardware

  29. Filter Drivers • 값을 추가하거나 디바이스의 상태를 수정하는 선택적인 드라이버 • 드라이버 스택 내의 Function Driver 상위 또는 하위에 존재 Upper Filter Function Driver Lower Filter Bus Driver Hardware

  30. WDM 드라이버 –일반적인 메시지 순서 • PnP 드라이버의 일반적인 이벤트 순서는 다음과 같습니다: • DriverEntry • AddDevice • LEGACY_BUS_INFORMATION • QUERY_RESOURCE_REQUIREMENTS • FILTER_RESOURCE_REQUIREMENTS 연결된 USB 디바이스 • START_DEVICE • QUERY_CAPABILITIES • QUERY_PNP_DEVICE_STATE • QUERY_DEVICE_RELATIONS • QUERY_DEVICE_RELATIONS 디바이스 시작 및 사용 준비 • QUERY_REMOVE • REMOVE • Unload 사용자가 디바이스 제거 요청

  31. WDM 드라이버 –DriverEntry • 드라이버를 처리하는 IRP를 위한 Dispatch Routine 설정 • 전역 변수 초기화 • 디바이스 오브젝트를 생성하지 않음 – AddDevice 호출 대기

  32. WDM 드라이버 –AddDevice • 디바이스가 감지될 때마다 모든 디바이스 요청 • Functional Device Object (FDO) 생성 • FDO를 PDO에 첨부 • Symbolic Link 또는 디바이스 인터페이스 인스턴스를 선택적으로 생성 • 그 디바이스를 위한 전원 상태 설정 • 실제 하드웨어를 억세스하지 않을 수도 있음 – IRP_MN_START_DEVICE 대기

  33. WDM 드라이버 –Plug and Play IRPs • 그 다음 메시지 셋은 IRP_MJ_PNP의 하위 함수입니다 : • LEGACY_BUS_INFORMATION • 내부적으로 사용됨. 스택내의 다음 디바이스로 전달. • QUERY_RESOURCE_REQUIREMENTS • 대부분의 Function 드라이버들이 이 IRP를 버스 드라이버상에 전달. • FILTER_RESOURCE_REQUIREMENTS • 하위 디바이스로부터 리턴되는 이 IRP를 수정하여, Function 드라이버는 디바이스의 리소스 요구량을 조정할 수 있음.

  34. WDM 드라이버 –IRP_MN_START_DEVICE • 디바이스가 준비되었을 때 드라이버로 전송됨 • 디바이스에 할당된 하드웨어 리소스가 드라이버로 전달됨 • 드라이버가 디바이스에 전원 공급 • 드라이버가 인터럽트를 연결하고 다른 장치의 초기화 수행.

  35. WDM 드라이버 –다른 Plug and Play IRP들 • IRP_MN_QUERY_CAPABILITIES • 스택 내의 모든 드라이버들이 디바이스 성능을 확인합니다. • IRP_MN_QUERY_PNP_DEVICE_STATE • 드라이버는 디바이스가 존재, 제거, 또는 사용 불가 되었는지 등을 반드시 지시해야 합니다. • IRP_MN_QUERY_DEVICE_RELATIONS • 버스 상에 어떤 디바이스가 존재하는지 알리기 위해서 버스 드라이버에 의해 처리됩니다.

  36. WDM 드라이버 –디바이스 제거 • IRP_MN_QUERY_REMOVE • 디바이스가 제거될 수 있는지 확인하기 위해 시스템에 의해 전송됨. • 드라이버는 남아있는 IRP들을 몰아내고 새로운 요청을 거부. • IRP_MN_REMOVE_DEVICE • 디바이스가 제거됨 • 드라이버는 모든 리소스를 해제해야 합니다. • Unload • DriverEntry 기간 동안 드라이버는 점유되었던 모든 리소스를 해제

  37. 귀하가 작성하는 드라이버의 유형에 따라, 처리해야 할 추가적인 메시지가 있습니다. : WDM 드라이버 –다른 PnP IRP들

  38. Plug and PlayState Machine © Microsoft Corporation (see DDK)

  39. WDM 드라이버-일반적인 PnP 핸들러 (DDK) case IRP_MN_QUERY_STOP_DEVICE: // // If we can stop the device, we need to set the HoldNewRequests flag, // so further requests will be queued. We don't care about processing // some old requests (if there are any), because we expect to be // started again in the future. // if (!fdoData->IsStarted) { // // If we aren't started, we'll just pass the irp down // A driver has no reason to veto a query when he // is stopped already. // IoSkipCurrentIrpStackLocation (Irp); status = IoCallDriver (fdoData->NextLowerDriver, Irp); SD_IoDecrement(fdoData); return status; } [continued]

  40. WDM 드라이버-일반적인 PnP 핸들러 (DDK) // // We can't be removed at this point // ASSERT(!fdoData->IsRemoved); status = pSD_CanStopDevice(DeviceObject, Irp); Irp->IoStatus.Status = status; if (NT_SUCCESS(status)) { // // First, don't allow any requests to be passed down // fdoData->HoldNewRequests = TRUE; SD_DebugPrint((3, "Query - stop holding requests...\n")); // // Then, wait for the existing ones to be finished // (since we expect to give up our resources, we // can't allow such requests). First, we need to decrement // this very operation (and to keep in mind not to decrement // after the switch). // SD_IoDecrement(fdoData); [continued]

  41. WDM 드라이버-일반적인 PnP 핸들러 (DDK) KeWaitForSingleObject( &fdoData->StopEvent, Executive, // Waiting for reason of a driver KernelMode, // Waiting in kernel mode FALSE, // No alert NULL); // No timeout IoSkipCurrentIrpStackLocation (Irp); status = IoCallDriver (fdoData->NextLowerDriver, Irp); goto exit; } else { // // The device can't be stopped, complete the request // IoCompleteRequest(Irp, IO_NO_INCREMENT); } break; [end]

  42. Plug and Play 요약 • Windows 2000을 위한 완벽한 WDM 드라이버의 제작은 복잡합니다! • 만약 귀하의 드라이버가 시스템에서 동적으로 제거될 수 있다면, 새로운 드라이버를 작성하십시오. 몇 가지는 재사용이 가능합니다. • 제거할 수 없는 디바이스를 위한 Legacy 드라이버는 재작성할 필요없이 WDM용으로 갱신이 가능합니다.

  43. Power Management • 적용 분야. . . • 다른 전원 레벨에서 동작하는 디바이스 • 외부 신호(전화 등)가 수신되면 휴지 상태의 시스템을 Wake up

  44. 전원 상태 • 두 가지 전원 상태 • 디바이스 전원 상태 • D0 – Fully powered (지원 필요) • D1 – Sleep 1 • D2 – Sleep 2 • D3 – Off (지원 필요) • 시스템 전원 상태 • S0 – On • S1 – Sleep 1 • S2 – Sleep 2 • S3 – Sleep 3 • S4 – Hibernate • S5 – Off

  45. 전원 관리 정책 소유자 • 전원 정책은 시스템 전원 상태를 디바이스 전원 상태에 매핑시킵니다. • 모든 물리적 디바이스에 대해, 디바이스의 전원 정책을 구현하는데 책임있는 드라이버는 하나가 존재합니다.

  46. 전원 정책 소유자 임무 • AddDevice 루틴 내에 디바이스의 초기 전원 상태 설정 • 시스템 상태 변경시 디바이스 전원 상태 수정 • 디바이스가 유휴상태인 것을 감지하면, 대기 상태로 전환 • 적절한 때가 되면 디바이스에 모든 전원을 리턴 • Wake-Up 신호가 발생한 것을 감지하고, 그 디바이스를 Wake Up

  47. 전원 관리 IRP들 • IRP_MJ_POWER의 하위 함수: • Power Manager에 의해 전송 • QUERY_POWER • SET_POWER • 전원 정책 소유자에 의해 전송 • WAIT_WAKE (시스템을 Wake Up시키는 디바이스에 의해 사용됨) • POWER_SEQUENCE (전원 상태 변화 최적화를 위해 사용됨)

  48. 전원 관리 책임 • 시스템 • 적절한 시스템 전원 상태 결정 • 시스템 상태를 드라이버에 공지 • 전원 관리 정책 소유자 • 시스템 상태에 근거하여 올바른 디바이스 전원 상태 결정 • SET_POWER IRP 요청 • 전원이 꺼진 상태에서는 IRP 프로세싱 연기 • 모든 WDM 드라이버 • POWER IRP가 디바이스 스택을 전달할 수 있도록 함

  49. 전원 관리 요약 • 전원 관리는 WDM 아키텍쳐의 중요한 컴포넌트입니다. • 전원 모델은 시스템 전원 상태와 디바이스 전원 상태를 사용합니다. • 전원 정책 관리자는 시스템 상태와 디바이스 상태를 매핑시킵니다. • 만약 귀하의 디바이스가 낮은 전원 상태를 가지고 있지 않고, 시스템을 Wake Up시킬 수 없다면, 전원 IRP를 디바이스 스택에 전달하기만 하면 됩니다.

More Related