1. USBDI / USBDI IOCTL / URB |
USBDI
USB를 지원하는 클래스 드라이버는 uhcd.sys, usbd.sys, usbhub.sys, usbui.sys로 구성되어 있으며 작성된 USB 드라이버와 가장 깊은 관계를 가진 드라이버는 usbd.sys이다. 이 드라이버가 USB 디바이스와 통신하는 기본 코드를 갖고 있다. 간단히 생각하면 USB 디바이스는 엔드포인트(endpoint)라는 다수의 논리적인 포트를 갖고 있으며 최하위 클래스 드라이버는 실제 포트와 맞물려 C 언어의 inp()나 outp()와 같은 최소 기능만 가진 라이브러리와 비슷하다.
USBDI IOCTL
드라이버 간에 내부 데이터 교환은 클래스 드라이버에 정의된 IOCTL을 사용한다. 이를 잊지 말기 바란다. USB 뿐만 아니라 다른 디바이스 관련 드라이버도 마찬가지이다. 제일 먼저 도움말에서 찾을 내용은 클래스 드라이버가 제공하는 IOCTL과 해당 IOCTL이 하는 일에 관련된 것으로, <표 1>에서 USB 클래스 드라이버가 제공하는 IOCTL을 살펴보기 바란다.
<표 1> USBDI 내부 IOCTL | |
IOCTL | 설명 |
IOCTL_INTERNAL_USB_SUBMIT_URB | 클래스 드라이버에 작업을 요청하고 결과를 기다린다. |
IOCTL_INTERNAL_USB_RESET_PORTUSB | 포트 재초기화 |
IOCTL_INTERNAL_USB_GET_PORT_STATUS | 현재 포트의 상태를 얻어온다. 리턴값은 다음과 같다.
USBD_PORT_ENABLED
USBD_PORT_CONNECTED |
IOCTL_INTERNAL_USB_ENABLE_PORT | 포트를 활성화한다. |
IOCTL_INTERNAL_USB_GET_HUB_NAME | USB 허브의 이름을 얻는다. |
IOCTL_INTERNAL_USB_GET_BUS_INFO | USB 버스 정보를 얻는다. 버스 정보는 USB_BUS_NOTIFICATION 구조체에 채워진다. |
URB
찾아낸 IOCTL을 다음 드라이버에 어떻게 전송할 것인가? 또한 <표 1>에 다뤄진 IOCTL만으로도 USB 드라이버와 모든 일을 처리할 수 있는가? 사실 <표 1>의 IOCTL을 전부 사용하지 않으며 주로 IOCTL_INTERNAL_USB_SUBMIT_URB를 IRP로 포장해 하위 드라이버에 전송한다.
USB 클래스 드라이버에 전달하기 위해 필요한 것은 다음과 같다.
① IRP를 생성한다. 상위 계층에서 내려오는 것이 아니며 현재 드라이버에서 하위 드라이버에 요청하므로 새로운 IRP를 생성해 전달시켜야 한다.
② 새로 생성한 IRP에는 하위 드라이버가 처리 가능한 정보를 담아야 한다. 다시 말해 IRP 형태가 하위 드라이버의 요구 형태에 맞춰져야 한다는 의미이다.
하위 드라이버가 처리할 수 있는 데이터 포맷은 미리 정의되어 있으며 각 디바이스마다 별개로 존재한다.
URB(USB Request Packet)는 USB 클래스 드라이버가 처리하는 패킷 포맷이다(DDK에서 패킷이라고 강조하므로 같은 말을 사용했다). 데이터 입출력과 상태 확인, 디스크립터 처리를 위한 많은 구조체를 유니언 형태로 내포하며 적당히 캐스팅해 사용하면 된다. 이와 비슷한 경우로 IEEE 1394에는 하위 드라이버에 작업 요청을 하기 위해 IRB를 사용한다. IRB에 대해 자세히 알고 싶으면 DDK 도움말을 참조하도록 하자.
디바이스에 직접 명령을 내리는 방법은 IRP를 새로 만들어 DriverObject를 생성할 때 저장한 하위 DriverObject에 IRP를 전달하고 처리 결과를 기다리는 것이다. 다만, 처리를 맡기는 대신 응답이 오지 않을 때에 대비해 이벤트를 설정하고 응답이 없을 경우 작업을 취소할 수 있도록 해야 한다.
IRP는 용도에 따라 생성하는 커널 모드 함수가 많다. 그 중 IOCTL을 기반으로 요구 패킷을 생성하는 IoBuildDeviceIoControlRequest()를 사용해 IRP를 만들어야 한다. 이 함수는 IOCTL, 하위 드라이버 포인터, 입출력 버퍼 인자 등을 받아들이지만 입출력 버퍼 인자는 사용할 필요가 없으니 값을 null로 넘겨준다. 그리고 하위 드라이버에 전달할 URB를 어딘가에 넣어야 하는데 USB의 내부 IOCTL은 STACK LOCATION의 입출력 버퍼를 사용하지 않는 대신 Paramters.Others.Argument1 멤버에 URB 포인터를 넣도록 되어있다. 주의하기 바란다.
<리스트 1>의 call_usbd()는 USB 드라이버에서 가장 많이 사용되는 함수이다. 이 함수는 URB를 다음 드라이버에 전송하고 그 결과가 나올 때까지 기다렸다가 결과값을 리턴하는 역할을 한다.
<리스트 1> call_usbd()의 예
NTSTATUS call_usbd (IN PDEVICE_OBJECT fdo, IN PURB p_urb)
{
NTSTATUS status = STATUS_SUCCESS;
PDEVICE_EXTENSION p_dev_ext;
PIRP irp;
c_event event;
IO_STATUS_BLOCK io_status;
PIO_STACK_LOCATION next_stack;
p_dev_ext = get_device_extension (fdo);
event.init ();
// 1) IRP 생성
irp =
IoBuildDeviceIoControlRequest (
IOCTL_INTERNAL_USB_SUBMIT_URB,
p_dev_ext->next_stack_driver,
NULL,
0,
NULL,
0,
TRUE,
event,
&io_status );
next_stack = IoGetNextIrpStackLocation (irp);
ASSERT (next_stack != NULL);
// 2) IRP에 URB 포함시킨다.
next_stack->Parameters.Others.Argument1 = p_urb;
// 3) 다음 드라이버에 IRP를 전달한다.
status = IoCallDriver (p_dev_ext->next_stack_driver, irp);
// 결과를 기다린다.
if (status == STATUS_PENDING)
status = event.wait (Suspended, KernelMode, FALSE);
else
io_status.Status = status; // 완료
status = io_status.Status;
// 4) 결과값 리턴
return status;
}
첫회에서 디바이스의 실제 제어는 메이저 IRP, IRP_MJ_PNP에서 처리한다고 설명했다. 드라이버 동작 후 실제 디바이스 인식은 IRP_MJ_PNP 메이저의 IRP_MN_START_DEVICE에서 처리하며, 이것이 보통 NT 드라이버와 다른 점이기도 하다.
디바이스의 설정, 무엇을 해야 하는가?
먼저 작성할 소스 코드를 차례대로 정리해 보겠다. 미리 이야기하는 것이지만 윈도우의 공통 컨트롤에서 값을 얻어와서 이를 다시 설정하는 과정과 흡사하다.
① USB 클래스 드라이버를 통해 디바이스 디스크립터를 얻어온다. 성공하면 DEVICE_EXTENSION에 디스크립터의 포인터를 저장한다.
② 컨피규레이션(configuration) 디스크립터를 요청해 얻어온다.
③ 컨피규레이션 디스크립터를 사용해 인터페이스 리스트를 가져온다. 이 인터페이스 리스트를 다시 재해석하도록 요청해 사용 가능한 인터페이스 리스트를 구한다.
④ 정해진 스펙 이외의 지정할 내용, 예를 들어 최대 전송량을 설정해야 한다면 이때 인터페이스를 차례로 검색하면서 값을 설정한다.
⑤ 재설정된 디스크립터를 디바이스에 적용하도록 요청한다.
⑥ DEVICE_EXTENSION에 값을 저장한다.
④ 과정에서 디스크립터에 값을 설정하는 것을 제외하면 하위 드라이버에 요청해 디스크립터를 얻어다 다시 디바이스에 설정하는 것을 반복했을 뿐이다. ④ 과정에서 인터페이스에 값을 다시 넣지만 보통의 디바이스에서는 생략해도 무방하며, 앞서 반복해 이야기했지만 USB는 실제 뭔가를 설정하는 것이 아니며 확인하는 것이 초기화 과정의 전부이다.
사용하는 함수는?
DDK가 제공하는 USB 관련 함수는 주로 어떤 일을 할까? 보통 클래스 드라이버에 작업을 요청하기 위해 필요한 IRP를 생성하는 것이 전부이다. <표 2>의 함수 이름을 눈여겨보기 바란다. 모든 함수 이름에 'Build'와 'Request'가 포함되어 있는데, 이는 특정 작업을 요청하기 위한 IRP를 생성해 달라는 의미이다. 강조하지만 NT 드라이버는 직접 값을 읽어오지 않는다. 대신 디바이스와 직접 통신하는 클래스 드라이버에게 뭔가를 요청하고 그 결과를 받아 사용한다.
<표 2> USB 주요 함수 | |
함수명 | 설명 |
UsbBuildGetDescriptorRequest | 디스크립터를 얻는 Request 패킷 생성 |
UsbBuildGetInterruptOrBulkTransferRequest | 데이터 전송 Request 패킷 생성 |
UsbBuildGetSelectConfigurationRequest | 컨피규레이션 디스크립터 선택 Request 패킷 생성 |
UsbBuildSelectInterfaceRequest | 인터페이스 선택 Request 패킷 생성 |
UsbBuildVenderRequest | OEM 작업 Request 패킷 생성 |
DDK의 USB 예제에는 디바이스 시작/초기화 과정을 3개 함수, 즉 StartDevice(), ConfigureDevice(), SelectInterface()로 나눠 실행한다. 한 함수에 묶는 것도 상관없지만 3가지로 나누도록 작성하는 것이 무리없을 듯 하다.
<리스트 2>는 일반적인 USB라면 전부 실행 가능한 초기화 코드를 나타냈다. 앞에서 설명한 내용과 비교하기 바란다. <리스트 2>의 내용이 이해되면 DDK의 USB 예제 중 bulk와 isochronous 예제에서의 디바이스 초기화 부분도 꼭 한 번 볼 것을 권한다.
<리스트 2> USB 디바이스 설정때 사용하는 함수
//
// IRP_MJ_PNP - IRP_MN_START_DEVICE에서 호출되며 USB 디바이스를 초기화한다.
//
NTSTATUS start_device (IN PDEVICE_OBJECT fdo)
{
PDEVICE_EXTENSION dev_ext;
PUSB_DEVICE_DESCRIPTOR p_usb_dev_desc = NULL;
PURB p_urb = NULL;
NTSTATUS nt_status;
ULONG siz;
trace ("ENTER start_device\n");
dev_ext = get_device_extension (fdo);
// 디스크립터를 얻기 위한 URB를 생성한다.
p_urb =
(PURB) new (NonPagedPool) struct _URB_CONTROL_DESCRIPTOR_REQUEST;
if (p_urb)
{
siz = sizeof(USB_DEVICE_DESCRIPTOR);
p_usb_dev_desc =
(PUSB_DEVICE_DESCRIPTOR) new (NonPagedPool) USB_DEVICE_DESCRIPTOR;
if (p_usb_dev_desc)
{
UsbBuildGetDescriptorRequest (
p_urb,
(USHORT) sizeof (struct _URB_CONTROL_DESCRIPTOR_REQUEST),
USB_DEVICE_DESCRIPTOR_TYPE,
0,
0,
p_usb_dev_desc,
NULL,
siz,
NULL );
// USB 클래스 드라이버에게 디스크립터를 얻어줄 것을 요청했다.
nt_status = call_usbd(fdo, p_urb);
}
else
{
nt_status = STATUS_INSUFFICIENT_RESOURCES;
}
// 성공했으므로 정보를 저장한다
if (NT_SUCCESS(nt_status))
dev_ext->usb_device_descriptor = p_usb_dev_desc;
else
delete p_usb_dev_desc;
delete p_urb;
}
else
nt_status = STATUS_INSUFFICIENT_RESOURCES;
// 디바이스 설정에 나선다
if (NT_SUCCESS(nt_status))
nt_status = configure_device (fdo);
if (NT_SUCCESS(nt_status))
{
dev_ext->f_device_started = TRUE;
dev_ext->f_device_removed = FALSE;
}
return nt_status;
}
//
// 디바이스 설정보다는 설정값을 얻어내는 것이 하는 일의 전부다.
//
NTSTATUS configure_device (IN PDEVICE_OBJECT fdo)
{
NTSTATUS nt_status = STATUS_SUCCESS;
PURB p_urb = NULL;
PDEVICE_EXTENSION dev_ext;
ULONG siz;
trace ("----------------------\n");
trace ("ENTER configure_device\n");
dev_ext = get_device_extension (fdo);
p_urb =
(PURB) new (NonPagedPool) struct _URB_CONTROL_DESCRIPTOR_REQUEST;
if (! p_urb)
return STATUS_INSUFFICIENT_RESOURCES;
siz = sizeof(USB_CONFIGURATION_DESCRIPTOR) + 512;
while( 1 )
{
dev_ext->usb_conf_desc =
(USB_CONFIGURATION_DESCRIPTOR*) new (NonPagedPool) CHAR[siz];
if (! dev_ext->usb_conf_desc)
{
delete p_urb;
return STATUS_INSUFFICIENT_RESOURCES;
}
UsbBuildGetDescriptorRequest (
p_urb,
(USHORT) sizeof (struct _URB_CONTROL_DESCRIPTOR_REQUEST),
USB_CONFIGURATION_DESCRIPTOR_TYPE,
0,
0,
dev_ext->usb_conf_desc,
NULL,
siz,
NULL );
nt_status = call_usbd (fdo, p_urb);
if (p_urb->UrbControlDescriptorRequest.TransferBufferLength > 0 &&
dev_ext->usb_conf_desc->wTotalLength > siz)
{
siz = dev_ext->usb_conf_desc->wTotalLength;
delete dev_ext->usb_conf_desc;
dev_ext->usb_conf_desc = NULL;
}
else
break; // we got it on the first try
} // while(retry loop)
delete p_urb;
//
// 인터페이스 설정
//
nt_status = select_interface (fdo, dev_ext->usb_conf_desc );
return nt_status;
}
//
// 인터페이스를 얻어내고 필요한 설정을 변경하고 다시 디바이스에 설정한다.
// 그러나 변경이 거의 없다.
//
NTSTATUS
select_interface (
IN PDEVICE_OBJECT fdo,
IN PUSB_CONFIGURATION_DESCRIPTOR conf_desc
)
{
NTSTATUS nt_status = STATUS_SUCCESS;
PURB p_urb = NULL;
PUSB_INTERFACE_DESCRIPTOR interface_desc = NULL;
PUSBD_INTERFACE_INFORMATION interface = NULL;
PDEVICE_EXTENSION dev_ext;
ULONG i;
USHORT siz;
trace ("ENTER select_interface\n");
dev_ext = get_device_extension (fdo);
p_urb = USBD_CreateConfigurationRequest(conf_desc, &siz);
if (p_urb)
{
interface_desc =
USBD_ParseConfigurationDescriptorEx (
conf_desc,
conf_desc,
-1,
-1,
-1,
-1,
-1 );
if (! interface_desc)
{
delete p_urb;
return STATUS_INSUFFICIENT_RESOURCES;
}
interface = &p_urb->UrbSelectConfiguration.Interface;
for (i=0; i< interface->NumberOfPipes; i++)
{
//
// 인터페이스를 변경하고 싶다면 이곳에서 한다. 그러나 생략해도 무방
//
}
UsbBuildSelectConfigurationRequest (
p_urb,
(USHORT) siz,
conf_desc );
nt_status = call_usbd (fdo, p_urb);
dev_ext->usb_conf_handle =
p_urb->UrbSelectConfiguration.ConfigurationHandle;
}
else
{
nt_status = STATUS_INSUFFICIENT_RESOURCES;
}
if (NT_SUCCESS(nt_status))
{
//
// configuration handle을 보관한다.
//
dev_ext->usb_conf_handle =
p_urb->UrbSelectConfiguration.ConfigurationHandle;
dev_ext->usb_interface =
(USBD_INTERFACE_INFORMATION*) new (NonPagedPool)
unsigned char[interface->Length];
if (dev_ext->usb_interface)
{
ULONG j;
//
// DEVICE_EXTENSION에 인터페이스를 보관한 후에 입출력할 때 사용한다.
//
RtlCopyMemory (
dev_ext->usb_interface,
interface,
interface->Length);
}
}
if (p_urb) delete p_urb;
return nt_status;
}
INF는 설치에 관련된 모든 정보를 담고 있는 배치 파일이다. 설치할 파일, 위치, 변경 혹은 추가할 레지스트리까지 하나의 파일에 모두 담는다. 또한 드라이버뿐만 아니라 일반 애플리케이션도 간단히 설치할 수 있도록 구성할 수 있다. 공개 프로그램인 ezpad는 INF 파일로 설치할 수 있도록 구성되어 있는 것으로 알고 있다. INF는 INI와 마찬가지로 섹션과 하부 엔트리 설정값으로 구성되어 있다. 섹션 문자열은 '[', ']'에 들어있고 하부 설정값은 항목 이름에 값을 대입하는 형식을 취한다. 주석은 INI와 마찬가지로 ';'를 사용한다.
INF는 최소한 16개 섹션을 갖게 된다. 설치 정보를 윈도우 95/98과 윈도우 NT/2000에 대해 별도로 갖고 있어야 하므로 별로 복잡하지도 않다. 자세한 내용을 알고 싶은 독자는 MSDN에서 INF 키워드로 검색하거나 비주얼 C++ 도움말에서 검색해 읽어보기 바란다. 한 페이지에 전부 설명되어 있지 않고 여러 갈래로 나눠져 설명되어 있다. 여기에서는 드라이버 설치에 필요한 것만 알아보고 넘어가겠다.
Strings 섹션
INF에서 사용할 문자열을 미리 정의한 부분으로, 별도로 문자열 섹션을 둔 이유는 한 가지 언어에 제한되지 않도록 하기 위함이다. 엔트리 이름에는 '.'이나 공백을 넣을 수 있으므로 이름을 지을 때 무척 자유롭다. DDK 예제에서는 제품명이나 제작사 이름, 문자열 이름 사이에 점을 넣어 구분해 사용한다. 이 섹션은 보통 INF의 제일 마지막에 위치한다.
[Strings]
WdmFrame.DeviceDesc="WDM Frame Device"
WdmFrame.ClassName="WDM Frame Device"
; ···
"WdmFrame.ClassName"이 엔트리명이며 그 뒤의 문자열이 정의할 값이다. 정의된 문자열을 "%문자열정의명%" 형식으로 사용한다. 문자열 "WDM frame Device"를 사용하려면 다음부터는 %WdmFrame.ClassName%을 적어주면 된다.
Version 섹션
모든 INF 파일에 공통으로 들어가는 섹션으로, 다음과 같은 하부 엔트리로 구성되어 있다.
◆ Signature : 설치할 운영체제를 명시한다. $Windows NT$, $Chicago$, $Windows 95$ 중에 하나만 적어야 한다. 대소문자를 가리므로 틀리지 않도록 하자. 윈도우 95/98과 2000에서 모두 사용하기 위해서는 어느 하나만 적기 곤란한데 $Windows NT$만 사용해도 별 문제가 없었다.
◆ Class : 드라이버 종류를 써줘야 하며 여기에서는 USB라고 적었다. 다른 값은 DDK 도움말에서 찾을 수 있다.
◆ ClassGUID : GuidGen.exe로 생성한 guid를 기록한다.
◆ Provider : INF 파일 작성자 이름이나 드라이버 제작사의 이름을 적어준다. String 섹션에 미리 정의하고 해당 엔트리로 대체한다.
Manufacturer 섹션
하위 섹션에 영향을 주는 섹션이다. 잠시 후에 참조 관계를 다루니 이 정도만 알고 넘어가자. 여기부터 설치 정보가 시작된다.
%WdmFrame.Manufacturer%=WdmFrame
SourceDisksNames 섹션
설치할 때 사용할 타이틀과 파일 위치를 기록한다. 파일 위치는 어디나 명시할 수 있지만 굳이 정하지 않아도 문제가 없다. 따라서 타이틀만 기록하고 나머지는 생략한다. 사용한 엔트리 이름은 다음 섹션인 SourceDisksFiles 섹션에서 참조한다. 엔트리 이름은 설치할 디스켓의 번호로, 작성자가 임의로 결정할 수 있다.
[SourceDisksNames]
1="WDM frame driver installation diskette","",,
SourceDisksFiles 섹션
복사할 파일을 적는다. 엔트리명은 해당 디스켓에 들어있어야 할 파일명이고 엔트리값은 SourceDisksNames 섹션에서 사용한 엔트리명이다. 다음 예와 앞의 예를 눈여겨보기 바란다.
[SourceDisksFiles]
WdmFrame.sys=1
DestinationDirs 섹션
파일이 복사될 위치를 정한다.
[DestinationDirs]
파일 리스트 섹션 = drid [,subdir]
이 섹션의 엔트리도 다른 섹션이 참조하는데 파일 리스트 섹션의 이름으로는 Copy Files, Rename Files, Delete Files 중 하나가 올 수 있다. 해당 섹션이 처리할 파일을 여기에 기록하는 것이다. drid에는 미리 정의된 위치값을 적으며 <표 3>에 나오는 값 중 하나를 사용한다. 많지는 않지만 전부 필요없을 것 같아 중요한 몇 가지만 적었다. 목록 전부를 보기 위해서는 MSDN에서 DestinationDirs로 정리된 도움말을 참조하자.
<표 3> DestinationDirs 섹션의 값 |
값 | 해당 위치 |
0xFFFF | INF가 위치한 현재 디렉토리 |
10 | Windows 디렉토리 |
11 | Windows 시스템 디렉토리(윈도우 95/98에서 %windir%\system, 윈도우 NT에서 %windir%\system32) |
12 | 드라이버 디렉토리(윈도우 NT의 %windir%\system32\drivers) |
30 | 부팅 파티션의 루트 |
INF 참조 관계
INF를 이해하려면 어디서 무엇을 참조해야 할까? 무엇이 어디에 포함되는지 이해하면 된다. 다음은 INF 섹션 간에 참조 관계에 포함되는 순서대로 적어놓았다. Manufacturer가 시작되며 참조 문자열의 시작이다. 참조의 기본 원칙은 상위 섹션의 엔트리값이 다음 하위 섹션의 이름이 된다는 것이다.
[Version]
[Strings]
[SourceDisksNames]
[SourceDisksFiles]
[DestinationDirs]
[Manufacturer]
Nobody Make=Nobody.Make
[Nobody.Make]
Driver 1=Driver1.Install,ID
[Driver1.Install]
CopyFiles=Driver1.CopyFiles
AddReg=Driver1.AddReg
[Driver1.CopyFiles]
; ···
[Driver1.AddReg]
; ···
INF 간단히 작성하기
윈도우 2000의 DDK에는 INF 작성을 도와주는 유틸리티인 GetInf.exe가 들어있지만 필자는 이 유틸리티를 사용하는 것보다는 예제 INF를 복사해 편집하는 것이 편했다. 사람마다 다를 수 있으니 자세한 것은 직접 실행해 확인하도록 한다. 이 유틸리티는 위저드 방식으로 실행되므로 차례대로 요구하는 값을 입력하면 INF를 생성해준다. <리스트 3>은 완전한 형태의 INF 예제이다. 앞과 뒤의 참조 관계를 확인하면서 읽어보기 바란다.
<리스트 3> INF의 예
; ---------------------------------------------------------------
; WDMFrame.sys를 설치하기 위해 작성한 INF
; ---------------------------------------------------------------
[Version]
Signature="$Windows NT$"
Class=USB
ClassGUID={A0401445-5366-11d3-AC7C-00A0C93E77E4}
Provider=%WdmFrame.Provider%
[Manufacturer]
%WdmFrame.Manufacturer%=WdmFrame
[ClassInstall32]
AddReg=WdmFrame.AddClassReg
[WdmFrame]
%WdmFrame.DeviceDesc%=WdmFrame.Install, USB\VID_04B4&PID_0002
[SourceDisksNames]
1=%WdmFrame.DriverDiskName%,"",,
[SourceDisksFiles]
WdmFrame.sys=1
[PreCopySection]
HKR,,NoSetupUI,,1
[DestinationDirs]
WdmFrame.CopyFiles = 10,system32\drivers
[WdmFrame.Install]
CopyFiles=WdmFrame.CopyFiles
AddReg=WdmFrame.AddReg
[WdmFrame.AddClassReg]
HKR,,,,%WdmFrame.ClassName%
[WdmFrame.AddReg]
HKR,,DevLoader,,*ntkern
HKR,,NTMPDriver,,WdmFrame.sys
[WdmFrame.CopyFiles]
WdmFrame.sys
;
; WinNT area
;
[WdmFrame.Install.NT]
CopyFiles= WdmFrame.CopyFiles
AddReg = WdmFrame.AddReg
[WdmFrame.AddReg.NT]
[WdmFrame.Install.NT.Services]
AddService = WdmFrame,0x00000002,WDM_Frame_Service_Inst,
[WDM_Frame_Service_Inst]
ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
StartType = 3 ;%SERVICE_AUTO_START%
ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
ServiceBinary = %12%\WdmFrame.sys
DisplayName = %WdmFrame.DeviceDesc%
;---------------------------------------------------------------
; INF에서 사용할 문자열이 정의되어 있다
;---------------------------------------------------------------
[Strings]
WdmFrame.Provider="nobody"
WdmFrame.Manufacturer="nobody"
WdmFrame.DeviceDesc="WDM Frame Device"
WdmFrame.ClassName="WDM Frame Device"
WdmFrame.DriverDiskName="WDM frame driver installation diskette"
드라이버 설치
드라이버 설치 화면은 윈도우 NT/2000과 윈도우 95/98이 서로 다르지만 내용은 거의 같으므로 여기에서는 윈도우 95/98을 기준으로 설명한다. 윈도우 NT/2000에서 드라이버를 동작시키기 위해서는 인내심이 필요한데 설치할 때마다 레지스트리를 검사하는 시간이 점점 늘어나기 때문이다. USB 디바이스를 PC에 연결하면 '새로운 디바이스 발견'했다는 메시지가 나타나고 이어 하드웨어 추가 마법사가 시작된다. <화면 1>에서 '알 수 없는 디바이스'라고 나타난 이유는 USB 컨트롤러에 디바이스 이름이나 회사에 관한 정보를 넣지 않았기 때문이다.
<화면 1> USB 디바이스 검색
지금 사용하는 USB 디바이스는 윈도우 95/98의 기본 목록에 없는 것이므로 직접 검색한다. '검색할 위치 지정'을 선택하고 드라이버가 있는 위치를 선택한다. 이후부터는 '다음'을 선택하는 것으로 드라이버 설치를 마칠 수 있다. 설치를 마치면 <화면 2>와 같이 INF에 적힌 문자열을 참조해 다이얼로그박스에 나타내 주었다.
<화면 2> USB 디바이스 설치 완료
드라이버 제거
드라이버는 레지스트리의 드라이버 정보와 설치할 때 시스템 폴더에 복사된 INF 파일, 해당 드라이버 파일을 삭제해야 한다. 개발 시에는 약간 번거롭지만 한 번 설치해 놓고 드라이버 파일만 교체해 사용할 수도 있다.
윈도우 95/98에서 드라이버 제거
정상적으로 설치된 레지스트리의 드라이버 정보는 HKEY_LOCAL_MACHINE\Enum\USB\ 아래에 서브키로 vid와 pid로 만들어진 문자열을 갖고 있다. 삭제하려면 해당 디바이스의 서브키를 삭제한다. 그리고 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\SetupX \INF\OEMName에는 설치된 드라이버에 관련된 INF 목록이 있다. 여기에서 해당되는 INF 파일을 삭제하면 된다. 또한 %WINDOWS%\INF\OTHER에 있는 INF 파일도 같이 삭제해야 한다. 만약 이 파일을 삭제하지 않으면 다음 디바이스가 인식될 때 드라이버를 자동으로 설치하므로 잊지 말아야 한다. INF의 파일명은 '회사명 + 원래이름.INF' 형태로 구성되어 있다.
윈도우 2000에서의 드라이버 제거
윈도우 2000에서는 사용자마다 레지스트리 접근 권한이 다르므로 administrator 계정으로 로그인해야 하며 regedit.exe 대신 regedt32.exe를 실행해 불필요한 레지스트리 정보를 삭제해야 한다. 그런데 administrator라 해도 레지스트리의 서브키를 함부로 삭제할 수 없다. 따라서 regedt32.exe의 security 메뉴를 통해 삭제하려는 레지스트리 키에 읽고 쓸 수 있는 권한을 준 다음 삭제해야 한다. 삭제할 위치는 HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Enum\USB이며 하위 키 중에서 자신의 드라이버를 찾을 수 있을 것이다.
INF를 삭제하려면 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup에서 드라이버의 INF 항목을 삭제한 다음 시스템 폴더인 %WINDOWS%\INF에서 설치할 때 사용한 INF를 지워야 한다. 그런데 여기에는 이름이 다르게 저장되어 있을 것이다. 많은 INF 중에서 oem?.inf가 있는데 이것을 하나씩 열어보고 자신이 사용한 INF를 찾아 지워줘야 한다. 마지막으로 당연히 sys 드라이버 파일도 삭제해야 한다.
무뎌지면 편하다
의의로 간단한 것에 놀라는 독자도 있을 것 같다. WDM은 기존 드라이버와 달리 쉽게 작성할 수 있도록 구성되었다. 다만 NT 드라이버에 대해 문외한이라면 익숙하지 않을 것인데, 이는 앞에서 말했듯이 무뎌지면 편해진다. USB 디바이스 인식과 설치 파일인 INF 작성에 대해 한회로 끝내기에는 아쉬움이 남는다. 다음호에는 USB로부터 값을 읽고 쓰는 방법에 대해 설명하도록 하겠다.d
Posted by 혁쌈
