KR20060047644A

KR20060047644A - 총칭 ｕｓｂ 드라이버

Info

Publication number: KR20060047644A
Application number: KR1020050036131A
Authority: KR
Inventors: 퍼도쉬 케이. 브헤사니아; 랜돌 이. 올
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-04-29
Filing date: 2005-04-29
Publication date: 2006-05-18
Also published as: JP5209125B2; JP5021180B2; KR101130474B1; US20050246455A1; JP5289592B2; US20050246723A1; US7577765B2; JP2005317019A; US7802022B2; JP2012099145A; EP1591891A3; JP2012128865A; CN100565484C; CN1716225A; EP1591891A2; US7650436B2; US20050246564A1

Abstract

총칭 USB 드라이버들을 제공하기 위한 기술들이 개시된다. 보다 구체적으로는, 총칭 커널-모드 드라이버를 액세스하는 사용자-모드 USB 라이브러리를 통하여 개발가능한 총칭 USB 디바이스 드라이버 아키텍처가 설명된다. 설명된 실시예에서, 본 방법은 디바이스의 플러그-인 이벤트에 응답하여 커널-모드 총칭 디바이스 드라이버를 로드하는 단계를 포함한다. 사용자 소프트웨어 컴포넌트는 상기 총칭 디바이스 드라이버와 통신하는 상기 총칭 사용자-모드 라이브러리{예컨대, 동적 링크 라이브러리(dynamic link library; DLL)}에 의해 제공되는 루틴들을 사용하여 상기 디바이스에 액세스한다.

총칭 USB 드라이버, 커널-모드, 사용자-모드, 사용자-모드 라이브러리, 플러그-인 이벤트, 사용자 소프트웨어 컴포넌트, 루틴

Description

총칭 ＵＳＢ 드라이버{GENERIC USB DRIVERS}

상세한 설명이 첨부되는 도면을 참조하여 기술된다. 도면에서, 참조번호의 제일 왼쪽의 숫자는 그 참조번호가 제일 먼저 나타난 도면을 식별한다. 상이한 도면에서 동일한 참조번호의 사용은 유사 또는 동일한 아이템을 의미한다.

도 1은 총칭 디바이스 드라이버를 위한 예시적인 시스템을 나타낸 도면.

도 2는 복수의 디바이스를 위한 복수 인스턴스의 총칭 디바이스 드라이버를 갖는 예시적인 시스템을 나타낸 도면.

도 3은 총칭 디바이스 드라이버를 사용하는 예시적인 방법을 나타낸 도면.

도 4는 총칭 디바이스 드라이버의 I/O를 핸들링 하는 예시적인 방법을 나타낸 도면.

도 5는 총칭 디바이스 드라이버의 전력 관리를 제공하는 예시적인 방법을 나타낸 도면.

도 6은 본 명세서에서 설명된 기술을 구현하는 데에 사용될 수 있는 일반적인 컴퓨터 환경을 나타낸 도면.

< 도면의 주요 부분에 대한 부호 설명 >

100 : 총칭 USB 시스템

102 : 커널-모드 환경

104 : 사용자-모드 환경

106 : USB 코어 스택

108 : 총칭 USB 드라이버

110 : 총칭 USB 사용자-모드 라이브러리

112 : 사용자 소프트웨어 컴포넌트

본 특허명세서의 개시 부분은 저작권 보호가 되는 내용을 포함한다. 저작권자는 본 특허명세서 또는 본 특허의 개시 내용 중 임의의 내용에 의한 팩시밀리 재생을 반대하지 않으며, 이는 그것이 Patent and Trademark Office의 특허 파일 또는 기록으로 보이기 때문이다. 그러나, 그렇지 않은 경우에는, 저작권자가 모든 저작권을 가진다. ⓒ2004 Microsoft Corporation. All rights reserved.

본 발명은 디지털 통신에 관한 것이며, 실시 측면에서는 총칭 범용 직렬 버스(generic universal serial bus; generic USB) 드라이버에 관한 것이다.

컴퓨터가 더 흔해질수록, 계속적으로 그 수가 증가해 온 기능들이 단일 컴퓨터 시스템에 포함된다. 때때로, 컴퓨터 시스템에 외부 디바이스가 부착됨으로써, 추가의 기능이 제공된다. 차례로, 외부 디바이스는 컴퓨터 시스템과 통신하여 추가의 기능을 제공한다.

범용 직렬 버스(USB)는 컴퓨터 시스템에 외부 디바이스를 연결하기 위한 표 준 통신 채널이 되어 왔다. USB는 상대적으로 높은 대역폭을 제공하면서 수많은 디바이스가 동일한 컴퓨터 시스템에 동시에 연결 가능하게 한다. 예를 들어, USB의 상업적으로 입수가능한 최근 버전(예를 들어, USB 2.0)은 480 Mbps(초당 메가 비트)까지 전송할 수 있다.

일반적으로 USB 디바이스를 제공하는 벤더는 이러한 디바이스에 액세스 가능하게 하는 디바이스 드라이버의 제공을 필요로 한다. 대개, 디바이스 드라이버는 컴퓨터 시스템이 디바이스에 액세스 가능하게 하는(예를 들어, 디바이스로부터 데이터의 판독, 데이터를 디바이스에 기록, 디바이스에 커맨드를 송신, 및 디바이스로부터 상태 데이터를 수신) 프로그램 및 데이터 세트이다.

현재, 대부분의 USB 디바이스 벤더는 그 디바이스를 위한 커널-모드(kernel-mode) 디바이스 드라이버를 제공하는 것을 필요로 한다. 일반적으로, 커널은 운영 시스템(operating system; OS)의 중심 부분으로서, 커널은 OS가 동작 중에 활동하고 컴튜터 시스템에 제어 하에 있다. 예를 들어, 커널은 컴퓨터 시스템에 (메모리 및 프로세스 관리와 같은) 필요한 서비스를 제공한다. 그 결과, 커널-모드 드라이버는 최소의 기능 불량(또는, 버그)의 경우에도 전 시스템에 미치는 회복 불가능한 파손의 원인이 쉽게 될 수 있다. 또한, 커널-모드의 USB 드라이버를 구현하는 것은 커널-모드 드라이버를 테스트하는 데에 필요한 추가의 하드웨어 또는 소프트웨어 이외에도, 복잡한 커널-모드 드라이버를 프로그래밍 해야 하기 때문에 시간 및 에너지의 투자가 필요하다. 더욱이, OS를 업그레이드 할 때, 비호환성 또는 구식의 커널-모드 디바이스 드라이버는 파손의 원인이 될 수 있으며, 성공적인 시스템 업그레이드를 방해할 수 있다.

요약

총칭 USB 드라이버를 제공하기 위한 기술이 개시된다. 더 구체적으로는, 총칭 USB 디바이스 드라이버 아키텍쳐가 기술되는데, 이는 총칭 커널-모드 드라이버와 통신하는 사용자-모드 USB 라이브러리를 통한 개발을 가능하게 한다.

기술된 실시예에서, 방법은 디바이스의 플러그-인 이벤트에 응답하여 커널-모드 총칭 디바이스 드라이버를 로딩하는 것을 포함한다. 사용자 소프트웨어 컴포넌트는 총칭 디바이스 드라이버와 통신하는 총칭 사용자-모드 라이브러리(예를 들어, 동적 링크 라이브러리(dynamic link library; DLL)에 의해 제공되는 루틴을 사용하여 디바이스에 액세스한다.

다른 실시예에서, 별개의 총칭 디바이스 드라이버가 각각의 플러그-인된 디바이스, 또는 디바이스에 의해 지원되는 각각의 기능을 위하여 로딩된다.

일부 실시예에서, 생산 아티클이 컴퓨터 프로그램 제품으로 제공된다. 컴퓨터 프로그램 제품의 일 실시예는 컴퓨터 시스템 및 컴퓨터 프로그램의 인코딩에 의해 판독 가능한 컴퓨터 프로그램 기억 매체를 제공한다. 컴퓨터 프로그램 제품의 다른 실시예는 컴퓨터 시스템 및 컴퓨터 프로그램의 인코딩에 의해 반송파로 구현되는 컴퓨터 데이터 신호로 제공될 수 있다.

더욱이, 컴퓨터 프로그램 제품은 컴퓨터 프로그램 상에서 실행하는 컴퓨터 프로세스를 위한 컴퓨터 프로그램을 인코딩한다. 컴퓨터 프로세스는 (플러그 앤 플레이 모듈에 의해 검출될 수 있는 바와 같이) 디바이스의 플러그-인 이벤트에 응답하여 커널-모드 총칭 디바이스 드라이버를 로딩한다. 사용자 소프트웨어 컴포넌트는 총칭 사용자-모드 라이브러리(예를 들어, 동적 링크 라이브러리(dynamic link library; DLL)에 의해 제공되는 루틴을 사용하여 디바이스에 액세스한다.

또한, 다른 실시예도 본 명세서에서 기술되고 인용된다.

이하의 개시 내용은 총칭 디바이스 드라이버 아키텍쳐를 제공하는 기술이다. 더 구체적으로, 총칭 USB 드라이버를 제공하는 기술이 개시된다. 더 구체적으로, 아키텍쳐는 총칭 커널-모드 드라이버에 액세스하는 사용자-모드 USB 라이브러리를 사용한다. 일부분, 아키텍쳐는 디바이스 드라이버의 개발 시간을 단축시키고, (예를 들어, 정규 동작 또는 업그레이드 프로세스 여부에 따라 전 시스템에 미치는 파손을 제한함으로써) 최종 사용자 경험을 향상시키고, 테스팅 및 디버깅을 집중시킨다. 또한, 아키텍쳐는 본 명세서에서 앞으로 논의될 바와 같이 입력-출력(I/O) 핸들링, 보안, 및 전력 관리를 향상시키기 위하여 사용될 수 있다. 더욱이, 본 명세서에서 논의되는 기술은 소프트웨어, 펌웨어, 하드웨어, 및/또는 그들의 조합으로서 구현될 수 있다.

총칭 드라이버의 개요

도 1은 총칭 디바이스 드라이버의 예시적인 시스템(100)을 나타낸 도면이다. 본 명세서의 도 1 및 도 2의 화살표의 방향은 구현에 따른 데이터 흐름의 방향을 나타낸다. 시스템(100)은 커널-모드 환경(102) 및 사용자-모드 환경(104)을 포함 한다. 커널-모드 환경(102)은 OS의 일부분일 수 있는 USB 코어 스택(106)을 포함하며, 하드웨어 레벨에서 USB 디바이스와 통신 가능하게 한다. 도 2를 참조하여 더 논의될 바와 같이, USB 코어 스택(106)은 허브 기능을 촉진할 수 있다. USB 코어 스택(106)은 총칭 USB 드라이버(108)에 연결된다. 총칭 USB 드라이버(108)는 USB 디바이스의 I/O를 관리하고, 더 일반적으로는 사용자-모드 환경(104)으로 USB 디바이스를 노출시킨다.

사용자 모드 환경(104)은 총칭 USB 사용자-모드 라이브러리(110) 및 사용자 소프트웨어 컴포넌트(112)를 포함한다. 따라서, 사용자 소프트웨어 컴포넌트(112)는 실시예의 사용자-모드 소프트웨어 컴포넌트이다. 총칭 USB 사용자-모드 라이브러리(110)는 USB 디바이스와 통신 또는 USB 디바이스를 제어하기 위하여 USB 사용자 소프트웨어 컴포넌트(112)에 의해 사용될 수 있는 루틴(또는 애플리케이션 프로그래밍 인터페이스(application programming interfaces; APIs)을 제공한다. 실시예에서, 총칭 USB 사용자-모드 라이브러리(110)는 DLL이다. 따라서, USB 사용자 소프트웨어 컴포넌트(112)는 커널 모드 대신에 사용자 모드의 루틴을 호출함으로써 사용자-모드 환경(104)으로부터 USB 디바이스를 관리할 수 있다. 이하에서 다양한 예시적인 API가 동일한 제목 하에 더 논의될 것이다.

USB 사용자 소프트웨어 컴포넌트(112)(또는 총칭 USB 사용자-모드 라이브러리(110)에 의해 제공되는 루틴)가 파손되는 경우에 커널의 동작은 영향을 받지 않기 때문에, 전 시스템에 미치는 파손을 저감시키기 위하여 그러한 실시예가 계획된다. 또한, 그러한 시스템(100)은 디바이스 드라이버의 개발 시간을 저감시키고, 테스팅 및 디버깅을 집중시킨다(부분적으로, 오직 하나의 컴퓨터 시스템이 USB 인터페이스를 테스트하기 위하여 필요하기 때문에, 즉 사용자-모드 소프트웨어 컴포넌트가 파손될 때라고 하여도, 시스템은 동작 상태를 유지한다).

일 실시예에서, USB 사용자 소프트웨어 컴포넌트(112) 및 총칭 USB 사용자-모드 라이브러리(110) 사이의 인터페이스에 관한 정보 뿐만 아니라, USB 코어 스택(106) 및 총칭 USB 드라이버(108) 사이의 통신 인터페이스에 대응하는 데이터는 개발자에게 또는 그렇지 않은 경우에는 사용 가능하게 공개된다. 일 실시예에서, 총칭 USB 드라이버(108) 및 총칭 USB 사용자-모드 라이브러리(110) 사이의 인터페이스에 관한 정보는 공개될 필요가 없다.

복수의 디바이스를 위한 총칭 드라이버

도 2는 복수의 디바이스를 위한 복수 인스턴스의 총칭 디바이스 드라이버를 갖는 예시적인 시스템을 나타낸 도면이다. 시스템(200)은 커널-모드 환경(102), 사용자-모드 환경(104), USB 코어 스택(106), 총칭 USB 사용자-모드 라이브러리(110), 및 USB 사용자 소프트웨어 컴포넌트(112)를 포함한다.

(이하에서 도 6을 참조하여 더 논의될 바와 같이) 시스템(200)은 데이터 통신을 위한 USB 버스(202)를 포함한다. USB 버스는 단지 하나의 예시가 아니며, (유선 또는 무선 통신 버스, 예를 들어, Bluetooth, 소형 컴퓨터 시스템 인터페이스(small computer system interface; SCSI) 등과 같은) 다른 형태의 데이터 통신 버스가 시스템(200)에서 사용될 수 있다.

도 2에 도시된 바와 같이, USB 버스(202)는 (도 1을 참조하여 논의된 바와 같이) USB 코어 스택(106)에 연결된다. USB 코어 스택(106)은 차례로 물리적 디바이스 객체(physical device object; PDO)에 연결되어 USB 허브(206)와의 통신을 용이하게 한다. USB 허브(206)는 복수의 USB 디바이스가 커널-모드 환경(102)에서 핸들링될 수 있도록 한다. 따라서, 총칭 USB 드라이버(108)는 커널-모드 환경(102) 및 사용자-모드 환경(104) 사이에서 연결될 수 있게 계획된다.

도 2에 도시된 바와 같이, 복수의 PDO는 다양한 드라이버(예를 들어, 총칭 USB 드라이버(108) 및 USB 복합 드라이버(208))와 통신이 용이할 수 있도록 사용될 수 있다. 사용자-모드 환경(104)은 세계 고유 식별기(globally unique identifier; GUID)(210)에 의해 발견 및/또는 식별된 기을을 통하여 각각의 총칭 USB 드라이버(108)와 통신할 수 있다. 각 GUID(210)는 고유하게 그 USB 인터페이스/기능을 식별한다. 하나의 예시적인 실시예에서, Washington, Redmond의 Microsoft Corporation을 통하여 입수가능한 Windows OS와 같은, OS 등록 파일 및/또는 드라이버 파일(예를 들어, 정보 파일(information file; IF))의 GUID 키를 위한 포맷은 다음과 같다:

HKR,,DeviceInterfaceGUID,,"{058815B2-9805-47d3-B7D5-ABC464D3CA06}"

따라서, 각각의 GUID(210)는 USB 사용자-모드 소프트웨어 컴포넌트(112)에 의해 사용될 수 있는 대응하는 디바이스에 의해 지원되는 기능을 식별한다. 예를 들어, 사용자-모드 소프트웨어 컴포넌트는 원하는 기능을 지원하는 디바이스(들)를 찾기 위하여 을 관심 있는 그들의 GUID를 노출시키는 임의의 드라이버를 탐색할 것이다. 그 후, USB 사용자-모드 소프트웨어 컴포넌트(112)는 도 1을 참조하여 논의 된 바 있는 총칭 USB 사용자-모드 라이브러리(110)를 통하여 USB 디바이스와 통신할 수 있다.

복수의 USB 허브(206)는 단일 USB 디바이스 내에 포함된 복수의 디바이스 또는 기능과의 통신이 허가되도록 사용될 수 있게 계획된다. 예를 들어, USB 허브(206)는 키 스트로크 버튼 또는 통합 포인팅 디바이스(예를 들어, 조이스틱 또는 터치 패드) 이외에, 멀티미디어 커맨드 버튼을 갖는 키보드 내의 상이한 기능에 액세스 가능하도록 사용될 수 있다.

총칭 디바이스 드라이버 동작

도 3은 총칭 디바이스 드라이버를 이용하기 위한 예시적인 방법(300)을 도시하고 있다. 플러그 앤 플레이(PNP) 모듈(예를 들어 OS 내에 있는)에 의해 검출되는 플러그인 이벤트가 발생하면, 코어 스택(예를 들어 도 1 및 2의 106)은 플러그-인된 장치에 상응하는 디바이스 ID를 추출한다. 이 추출된 디바이스 ID는 PNP 모듈(306)에 의해 제공되거나 검출되며, PNP 모듈은 추출한 디바이스 ID를 총칭 드라이버(308, 예를 들어 도 2의 108)에 매치시킨다.

매치가 이루어진 총칭 드라이버(예를 들어 도 1 및 2의 108)는 스테이지(310)의 로딩된 디바이스 드라이버와 사용자 소프트웨어 컴포넌트(예를 들어 도 1 및 2의 112) 사이의 통신을 용이하게 하기 위해 로딩된다. 단계 312에서, (도 2의 210을 참조하여 논의된 바와 같은) 고유 ID가 등록된다. 최종적으로, 플러그-인된 디바이스는 총칭 디바이스 드라이버를 통해 사용자 소프트웨어 컴포넌트에 의해 액세스된다.

일 실시예에 있어서, PNP 모듈이 추출된 디바이스 ID를 다른 디바이스 ID보다 총칭 디바이스 드라이버(예를 들어, 플러그-인된 디바이스와 호환성이 있는 총칭 디바이스 드라이버)에 매치시키는 것이 계획된다. 이는 임의의 추가적인 드라이버들의 로딩에 대한 필요성을 차례로 제거한다. 따라서, 일 실시예에 있어서, 커널-모드의 총칭 디바이스 드라이버는 장치의 플러그인 이벤트에 대응하여 로딩되고, 사용자 소프트웨어 컴포넌트는 일반적인 사용자-모드 라이브러리에 의해 제공되는 루틴들을 이용함으로써 디바이스에 액세스한다. 일반적인 사용자-모드 라이브러리는 총칭 디바이스 드라이버에 통신상으로 결합된다. 루틴들은 API들(후술하는 "예시적인 API들"에서 보다 상세하게 논의될 것임)로서 실행된다. 나아가, 개별적인 총칭 디바이스 드라이버는 각각의 플러그-인된 장치들(또는 장치에 의해 서포트되는 기능들)을 위해 로딩될 수 있다.

총칭 디바이스 드라이버들에 있어서의 I/O 핸들링

도 4는 총칭 디바이스 드라이버들에 있어서의 I/O 핸들링에 대한 예시적인 방법(400)을 도시하고 있다. 일 실시예에 있어서, 상기 방법(400)은 사용자 소프트웨어 컴포넌트(예를 들어 도 1 및 2의 112)가 몇 가지 루틴의 소환에 의해 하드웨어의 특정 I/O 핸들링을 총칭 디바이스 드라이버들에게 위임할 수 있도록 한다. 예를 들어 사용자 소프트웨어 컴포넌트는 일반적인 USB 사용자-모드 라이브러리(예를 들어 도 1의 110)를 통해 제공되는 초기화, 판독/기록 및 릴리스의 명령을 단순히 내리고, 총칭 디바이스 드라이버에 특정 데이터 길이의 고려, 데이터의 단편화 및/또는 데이터 리어셈블리를 위임한다.

예를 들어, 초기화는 일반적인 USB 디바이스 드라이버의 상태 및 디폴트에 대한 행동을 리셋하고 추가 동작을 처리하기 위한 일반적인 USB 디바이스 드라이버를 준비한다. 판독은 대응 하는 장치 상의 특정 엔드포인트로부터의 데이터를 판독하고 쓰기는 대응하는 장치 상의 특정 엔드포인트에 데이터를 기입한다. 릴리스는 초기화와 함께 개시되었던 세션동안 요구된 모든 리소스들을 정리한다.

데이터 길이의 고려와 관련하여, USB 입력(즉, 도 5를 참조하여 논의되는 장치로부터 호스트 또는 컴퓨팅 시스템으로의 데이터) 엔드포인트는 한 번에 0바이트에서 엔드포인트의 특정된 최대 패킷 사이즈까지 어디로든 전송할 수 있으며, 호스트 시스템 상의 소프트웨어는 전송(전송은 복수의 패킷으로 구성된다)에 있어서의 각 패킷을 위한 최대 사이즈까지 수신하도록 준비될 필요가 있다. 사용자-모드 소프트웨어 컴포넌트(예를 들어 도 1 및 2의 112)가 복수의 최대 패킷 사이즈가 아닌 전송을 요청하면, 일반적인 USB 디바이스 드라이버는 자동으로 이 전송의 사이즈를 조정한다. 따라서, 사용자 소프트웨어 컴포넌트가 장치로부터 모든 가능한 데이터 전송의 크기를 처리하기에 불충분한 길이의 데이터 전송을 요청하면, 데이터 전송의 길이가 증가된다. 이는 적어도 두 개의 독립적인 전송(이는 또한 "분할"이라고도 한다)에서의 클라이언트(클라이언트는 사용자-모드 소프트웨어임)의 버퍼를 분할하는 것에 의해 달성된다. 첫번째 전송 사이즈는 클라이언트가 요청한 전송 사이즈보다는 작은 최대의 복수의 패킷 사이즈(이하 "MaxPacket"이라 함)이 될 수 있다. 이 첫번째 전송을 위한 버퍼는 클라이언트의 버퍼의 첫번째 N*MaxPacket(이 값은 첫번째 서브 전송의 크기임)이며, 메모리 복사는 요구되지 않 는다. 두번째 전송은 MaxPacket 바이트이다. 이 두번째 전송을 위한 버퍼는 실행에 있어서 새로이 할당된 버퍼이다. 일단 두 전송이 이루어지면, 두번째 전송으로부터의 데이터는 클라이언트의 버퍼가 전부 차거나 쇼트 패킷이 도달할 때까지 클라이언트의 버퍼로 복사된다. 복사 후에 두번째 전송으로부터 어떤 데이터가 남는다면, 엔드포인트를 위한 파이프 정책에 기초하여, 다음 전송 요청을 위해 떨어져 저장되거나 저장되지 않을 수 있다. 첫번째 전송 내에 쇼트 패킷이 있다면, 두번째 전송은 일어나지 않도록 계획될 수 있다.

더욱이, USB 코어 스택(예를 들어 도 1 및 2의 106)과 관련있는 USB 호스트 콘트롤러는 종종 전송 버퍼를 특정 사이즈로 조절한다. 이 사이즈는 다른 호스트 콘트롤러 실행과는 다르다. 일반적인 USB 디바이스 드라이버는 이들 사이즈의 한계를 고려하고, 클라이언트의 전송 요청이 한계를 초과하는 경우에는 그 전송은 한계보다 작거나 동등한 두 개 이상의 전송으로 나누어진다. 일 실시예에 있어서, 각 서브 전송의 버퍼가 단지 클라이언트의 오리지널 버퍼의 부분으로서의 이를 실행하기 위해 버퍼가 요구되지는 않는다.

도 4에 도시한 바와 같이, 방법(400)은 스테이지(402)에서, 예를 들어 장치에 액세스 하기 위해 이용되는 데이터 구조를 정의함으로써 초기화한다. 상기 초기화 스테이지는 값(WinUsb_Initialize와 같은 예시적인 API와 관련하여 이하에서 상세하게 논의되는)들을 디폴트 하기 위한 정책 설정을 리셋한다. 초기화 스테이지는 일반적인 사용자-모드 라이브러리(예를 들어 도 1 및 2의 110과 관련되는 DLL)가 일 실시예에 있어서 구동될 수 있도록 한다.

방법(400)은 예를 들어 타임 아웃, 패킷의 종료, 에러로부터의 자동 복구, 패킷 종료 가이드라인, 쇼트 패킷 처리, 전송되는 데이터의 양을 예상하기 위해 실제 데이터에 앞서 헤더를 판독하기 위해 사용되는 부분 판독, 인터레스트가 없는 여분 데이터의 포기 및/또는 처리되지 않은 데이터 처리(이는 사용자 소프트웨어 컴포넌트가 적절한 데이터 처리를 보장함을 나타낸다) 등을 포함하는 총칭 디바이스 드라이버의 행동을 정의하는 파이프 정책(404)을 정의하며, 이는 WinUsb_SetPipePolicy와 같은 예시적인 API와 관련하여 이하에서 상세하게 논의될 것이다. 일 실시예에 있어서, 각 엔드포인트는 개별적으로 형성가능한 일반적인 USB 드라이버 내에 파이프를 가질 수 있다.

이들의 예시적인 파이프 행동 설정의 일부는 다양한 실시예와 관련하여 아래에서 상세히 논의된다:

● 타임아웃 이 파이프 정책은 특정 엔드포인트를 위해 설정될 수 있고, 시간의 특정 양 이내에 수행되지 않는 엔드포인트를 위한 임의의 전송을 취소시킬 수 있다.

● 패킷 종료 가이드라인 일부 USB 장치 프로토콜은 호스트 컴퓨팅 시스템이 출력 전송(호스트로부터 장치로의)의 종료를 쇼트 패킷(엔드포인트의 특정된 임계 최대 패킷 사이즈보다 작은 패킷)으로 표시하는 것을 요구한다. 클라이언트의 전송이 복수의 최대 패킷 사이즈이면, 길이가 0인 패킷이 전송된다. 이는 사용자 소프트웨어 컴포넌트(또는 클라이언트)를 위해 자동으로 행해지며, 클라이언트는 최대 패킷 사이즈나 전송이 복수의 사이즈인지 여부를 걱정할 필요가 없다.

● 에러로부터의 자동 복구 특정 엔드포인트 상의 특정 전송을 위한 USB 버스 상에 전송 에러가 있는 경우, 자동 복구 메커니즘이 에러 조건을 제거하기 위한 시도를 할 수 있으며, 추가되는 전송은 생략하라는 명령이 발해진다. 또한 에러 조건은 회복 불가능한 것으로 계획될 수도 있다(즉, 더 이상의 전송은 발생하지 않는다).

● 쇼트 패킷 처리 일반적으로, 쇼트 패킷이 USB 장치 상의 특정 엔드포인트로부터 수신될 때, 그 전송은 USB 코어 스택에 의해 이루어진다(예를 들어 도 1 및 2의 106). 가끔씩 사용자 소프트웨어 컴포넌트는 전송의 완성을 야기하는 이를 의도하는 것이 아니라 특정 수의 바이트가 수신될 때까지 장치로부터의 판독을 금지한다. 일 실시예에 있어서, 이는 그러한 이벤트들을 무시하고 판독을 금지하기 위한 총칭 USB 디바이스 드라이버를 구성함으로써 처리될 수 있다. 이는 직전에 수신한 바이트를 통과한 하나의 바이트를 가리키는 버퍼에 이른 명령을 재발행 하는 것에 의해 실행된다.

● 부분 판독 일부 디바이스 프로토콜은 전송의 시작에 사이즈 정보, 전송 타입 등을 포함하는 데이터에 관한 정보를 포함하는 헤더를 포함한다. 일부 클라이언트는 전송의 나머지를 어떻게 처리할 것인지를 결정하기에 앞서 이 헤더만을 판독하기를 원한다. 이러한 시나리오를 처리하기 위해, 클라이언트는 클라이언트가 대응하는 파이프(전송이 목표로 하는)를 위한 헤더만을 판독하는 것을 허용하는 행동을 설정하고, 총칭 USB 디바이스 드라이버는 패킷 내의 헤더 후에 수신된는 임의의 추가적인 데이터를 저장하며, 그 결과 클라이언트의 이어지는 전송의 시작에 부가된다.

● 여분 데이터의 포기 디바이스가 클라이언트 요청보다 패킷 내에 더 많은 데이터를 보낸다면, 클라이언트는 여분의 데이터를 포기하거나 이어지는 전송의 시작에 부가되도록 저장하기 위해 엔드포인트를 위한 USB 디바이스 드라이버 행동을 형성한다.

● 처리되지 않은 데이터 일부 클라이언트는 예를 들어 특정 장치 특징과 관련하여 성능을 향상시키기 위해, 총칭 USB 디바이스 드라이버의 자동 행동 보정을 무시하기 위해 자체적으로 전송 한계를 관리한다. 이들 클라이언트들은 특정 엔드포인트에 대한 총칭 USB 디바이스 드라이버 행동을 형성함으로써, 클라이언트의 행동을 수정하기보다는 클라이언트 행동의 수정을 요구한다. 따라서 이러한 접근은 모든 적절하게 행동된 클라이언트 요청들이 코어 USB 스택으로 직접 통과되는 것을 허용한다.

일 실시예에 있어서, 사용자 소프트웨어 컴포넌트는 FIFO 버퍼 정책{예를 들어 특정 파이프(엔드포인트)에 대한}을 정의하고, 장치(408)로부터 FIFO를 전송하기 시작한다. 이는 WinUsb_SetFifoPolicy 및 WinUsb_StartFifo와 같은 예시적인 API들과 관련하여 이하에서 상세히 논의된다. 그리고 FIFO는 판독된다(예를 들어 이하에서 논의되는 WinUsb_ReadFifo API를 호출함으로써). 일 실시예에 있어서, 하나의 FIFO가 각각의 파이프를 위해 제공된다. 또한 WinUsb_ReadPipe를 사용함으로써 데이터가 판독되도록 계획될 수 있다. 따라서, FIFO는 데이터 판독을 위해 요구되지 않는다. 그러나, FIFO는 예를 들어 임의의 시간에 데이터를 발생시키거 나, 데이터가 끊임없이 계속되도록 하기 위해, 장치의 특정 클래스를 위해 사용될 수 있다.

파이프는 스테이지(410)에서 판독되거나 기입될 수 있다. 더욱이, 아래에서 상세히 설명하는 바와 같이, 사용자 소프트웨어 컴포넌트가 더욱 정밀하게 I/O 기능을 제어할 수 있도록 하는 I/O 처리를 위한 다른 API들도 이용 가능하다. 예를 들어, 일 실시예에 있어서, 장치가 클라이언트 버퍼에 비해 지나치게 큰 패킷에 응답한다면, 데이터는 다음 전송의 시작 부분에 추가될 것이다(이 옵션이 가능하다면, 예를 들어 Allow_Partial_Reads).

예시적인 API들

도 1 및 2를 참조하여 논의된 루틴을 제공하기 위해 Microsoft Windows 환경 내에서 이용되는 하나 이상의 예시적인 API들이 도시된다. 예를 들어, 루틴들(예를 들어 도 1 및 2의 일반적인 USB 사용자-모드 라이브러리 내의)은 이어지는 동작들(이하에서 논의되는)을 서포트한다:

● USB 설명에 대한 질문: 장치, 구성, 인터페이스 및 스트링;

● GUID 디바이스 인터페이스 클래스에 관련된 USB 디바이스 인터페이스의 계산 및 벤더가 제공하는 회수 루틴을 이용한 제거;

● USB 디바이스의 인터페이스들의 선택적인 활성화 및 다른 것들의 비활성화;

● 표준의 제어 전송 요청의 발생; 및/또는

● 제어, 벌크, 인터럽트 및 등시성 데이터의 전송.

후술하는 예시적인 API들은 그들이 Microsoft Windows OS를 위한 총칭 USB 디바이스 드라이버에 대응함을 나타내는 "WinUSB"에 의해 서문이 된다. 다른 명명의 규칙이 이용될 수도 있다. 또한, 각 API를 위한 샘플 호출, 파라미터 및 리턴 값들은 아래에서 강조된다.

1. WinUsb_Initialize

WinUsb_Initialize 함수는 WinUsb 데이터 구조체(data structures)를 초기화한다. 이 함수가 호출되면, 정책 설정(policy settings)은 디폴트 값으로 리셋되는 것에 유의해야 한다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다.

BOOL _stdcall

WinUsb_Initialize(

IN HANDLE DeviceHandle,

OUT PWINUSB_INTERFACE_HANDLE InterfaceHandle

);

파라미터들

DeviceHandle

파일(예컨대, CreateFile)을 생성하기 위하여 루틴(routine)에 의해 리턴된 디바이스에 대한 핸들. WinUsb는 오버랩된 I/O(overlapped I/O)를 사용하고, 그래서 플래그(예컨대, FILE_FLAG_OVERLAPPED)는 CreateFile 호출에서 지정되어야 한다.

InterfaceHandle

이것은 모든 다른 WinUSB API 함수 호출을 위해 사용될 수 있는 인터페이스 핸들이다. 이것은 WinUSB에 의해 생성되는 불투명 핸들(opaque handle)이다.

리턴 값

이 함수는 성공이면 TRUE를 리턴한다. 그렇지 않으면, FALSE를 리턴하고, 로그된 에러(logged error)는 GetLastError를 호출함으로써 조회될(retrieved) 수 있다.

2. WinUsb_Free

WinUsb_Free 함수는, WinUsb_Initialize에 의하여 할당된 모든 자원을 해제(free)한다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다.

BOOL _stdcall

WinUsb_Free(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의하여 리턴된 인터페이스 핸들이다.

리턴 값

이 함수는 성공이면 TRUE를 리턴한다. 그렇지 않으면, FALSE를 리턴하고, 로그된 에러는 GetLastError를 호출함으로써 조회될 수 있다.

3. WinUsb_QueryAlternateInterface

WinUsb_QueryAlternateInterface 함수는 특정 인터페이스 핸들에 대한 제1 대체 인터페이스 기술자(alternate interface descriptor)를 리턴한다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다.

BOOL _stdcall

WinUsb_QueryAlternateInterface(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR AlternateInterfaceNumber,

OUT PUSB_INTERFACE_DESCRIPTOR UsbAltInterfaceDescriptor

);

파라미터들

InterfaceHandle

AlternateInterfaceNumber

이것은 리턴될 대체 인터페이스를 가리키는 값이다. 0의 값은 제1 대체 인터페이스를 가리키고, 1의 값은 제2 대체 인터페이스를 가리킨다. 등등

UsbAltInterfaceDescriptor

호출자 할당 USB_INTERFACE_DESCRIPTOR 구조체에 대한 포인터.

리턴 값

이 함수는 성공하고 구조체를 실장(populate)하면 TRUE를 리턴한다. 그렇지 않으면, FALSE를 리턴하고, 로그된 에러는 GetLastError를 호출함으로써 조회될 수 있다.

4. WinUsb_QueryDeviceInformation

WinUsb_QueryDeviceInformation 함수는, WINUSB 인터페이스와 연관되는 물리적 디바이스에 관한 정보를 리턴한다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다.

BOOL _stdcall

WinUsb_QueryDeviceInformation(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN ULONG InformationType,

IN OUT PULONG BufferLength,

OUT PVOID Buffer

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

InformationType

이것은 어느 인터페이스 정보 값을 조회할지를 지정하는 값이다.

BufferLength

이것은 판독할 바이트의 최대 수 또는 버퍼의 바이트로의 길이이다. 이 파라미터는 버퍼로 복사된 바이트의 실제 수로 설정될 수 있다.

Buffer

이것은 요청된 값을 수신하는 호출자 할당 버퍼이다.

리턴 값

이 함수는 성공하고 구조체를 실장하면 TRUE를 리턴한다. 그렇지 않으면, FALSE를 리턴하고, 로그된 에러는 GetLastError를 호출함으로써 조회될 수 있다.

주석

다음 리스트는 가능한 InformationType 값을 설명한다.

DEVICE_SPEED (0x01)

이 요청은 디바이스의 속도에 기초하여 다음의 값 중 하나를 리턴할 것이다.

LowSpeed (0x01)

FullSpeed (0x02)

HighSpeed (0x03)

PHYSICAL_DEVICE_ID (0x02)

이 값은 디바이스의 물리적 디바이스 식별자(physical device identifier)를 포함한다.

5. WinUsb_GetDescriptor

WinUsb_GetDescriptor 함수는 요청된 기술자를 리턴한다. 이 API를 호출하기 위한 예시적인 메소드는 다음가 같다:

BOOL _stdcall

WinUsb_GetDescriptor(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR DescriptorType,

IN UCHAR Index,

IN USHORT LanguageID,

OUTPUT PUCHAR Buffer,

IN ULONG BufferLength,

OUT PULONG LengthTransferred

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

DescriptorType

이것은 리턴될 기술자의 유형을 지정하는 값이다. 표준 값(standard values)을 위하여, http://www.usb.org에서 이용가능한 USB 사양(specification)이 참조될 수 있다.

Index

이것은 USB 사양에서 제공되는(documented) 기술자 인덱스이다.

LanguageID

이것은, 요청된 기술자가 스트링 기술자(string descriptor)이면, 언어 식별자를 지정하는 값이다.

Buffer

이것은 요청된 기술자를 수신하는 호출자 할당 버퍼이다.

BufferLength

이것은 판독될 바이트의 최대 수 또는 버퍼의 바이트로의 길이이다.

LengthTransferred

이것은 버퍼에 복사된 바이트의 실제 수를 수신한다.

리턴 값

6. WinUsb_SetCurrentAlternateInterface

WinUsb_SetCurrentAlternateInterface 함수는 인터페이스를 위한 지정된 대체 인터페이스 설정을 선택한다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL _stdcall

WinUsb_SetCurrentAlternateInterface(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR InterfaceNumber

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

InterfaceNumber

이것은, WinUsb_QueryAlternateInterface에 의하여 실장된 PUSB_INTERFACE_DESCRIPTOR 구조체의 bInterfaceNumber 멤버에 포함되는 값이다.

리턴 값

7. WinUsb_GetCurrentAlternateInterface

WinUsb_GetCurrentAlternateInterface 함수는 인터페이스에 대한 현재의 대체 인터페이스 설정을 가져온다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL _stdcall

WinUsb_GetCurrentAlternateInterface(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

OUT PUCHAR InterfaceNumber

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

InterfaceNumber

이것InterfaceNumber은 현재 선택된 대체 인터페이스를 수신할 UCHAR에 대한 포인터이다.

리턴 값

8. WinUsb_QueryPipe

WinUsb_QueryPipe 함수는 인터페이스와 연관되는 지정된 파이프에 대한 파이프 정보를 리턴한다. 디폴트 제어 파이프는 리턴되지 않을 수 있다는 것에 유의해야 한다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL _stdcall

WinUsb_QueryPipe(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR AlternateInterfaceNumber,

IN UCHAR PipeIndex,

OUT PWINUSB_PIPE_INFORMATION PipeInformation

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

AlternateInterfaceNumber

이것은 정보가 리턴될 대체 인터페이스를 지정하는 값이다.

PipeIndex

이것은 정보가 리턴되는 파이프를 지정하는 값이다. 이 값은 일 구현예에서의 PipeId와 동일하지는 않다. 대신, 이것은 인터페이스의 리스트의 파이프를 가리킨다. 0의 값은 제1 파이프를 표명하고(signifies), 1의 값은 제2 파이프를 표명하는 등이다. 이 값은 인터페이스의 기술자의 bNumEndpoints 보다 작아야 한다.

PipeInformation

이것은 호출자 할당 WINUSB_PIPE_INFORMATION 구조체에 대한 포인터이다.

리턴 값

주석

WINUSB_PIPE_INFORMATION 구조체의 정의는 다음과 같을 수 있다:

typedef struct _WINUSB_PIPE_INFORMATION {

USBD_PIPE_TYPE PipeType;

UCHAR PipeId;

USHORT MaximumPacketSize;

UCHAR Interval;

} WINUSB_PIPE_INFORMATION,

*PWINUSB_PIPE_INFORMATION;

PipeId 멤버는 7비트 주소 및 방향 비트(direction bit)를 포함하는 USB 8비트 (16진법) 디바이스 ID 주소(endpoint address)이다.

9. WinUsb_SetPipePolicy

WinUsb_SetPipePolicy 함수는 특정 파이프(엔드포인트)를 위한 정책을 세팅한다. 상기 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL __stdcall

WinUsb_SetPipePolicy(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR PipeID,

IN ULONG PolicyType,

IN ULONG ValueLength,

IN ULONG_PTR Value

);

파라미터들

InterfaceHandle

이는 WinUsb_Initialize에 의해 반환되는 인터페이스 핸들이다.

PipeID

이는 정책을 세팅할 파이프의 파이프 식별자이다.

PolicyType

이는 변경할 정책 파라미터를 지정하는 값이다.

ValueLength

이는 Value가 가리키는 또는, Value가 버퍼를 가리키지 않은 경우에는 0인, 바이트 단위의 버퍼 길이이다.

Value

PolicyType에 의해 지정된 정책 파라미터에 대한 새로운 값

리턴 값

상기 함수는 구조체를 성공적으로 생성한 경우에 TRUE를 리턴한다. 그렇지 않으면, FALSE를 리턴하고, 로그된 에러는 GetLastError를 호출함으로써 검색할 수 있다.

주석

다음 목록은 가능한 PolicyType 값들을 기술한다.

SHORT_PACKET_TERMINATE(0x01)

Value가 (0이 아닌)TRUE이면, 엔드포인트에 대한 최대 패킷 크기의 수배에 해당하는 모든 WRITE(OUT) 요청은 길이가 0인 패킷으로 종료된다. 디폴트는 FALSE이다.

AUTO_CLEAR_STALL(0x02)

Value가 (0이 아닌)TRUE이면, 실장 PID(stall PID)는 무시되고, FIFO(First In, First Out)버퍼링이 사용되고 있지 않으면, 에러가 리턴된다. 그러나, 이러한 경우에, 파이프는 중단되지 않고, 데이터를 계속하여 전달할 것이다. 상기 파라미터는 CONTROL 파이프들에 아무런 영향을 미치지 않는다. 주의할 점은, 호스트는 자동적으로 장치 실장 조건을 클리어한다는 점이다. 디폴트는 FALSE이다.

PIPE_TRANSFER_TIMEOUT(0x03)

Value는 그 후에 전송이 취소되어야 할 밀리세컨드 단위의 시간이다. 0이라는 값은 무한 시간을 의미한다. 디폴트는 무한 시간이다.

IGNORE_SHORT_PACKETS(0x04)

Value가 (0이 아닌)TRUE이면, 짧은 패킷이 수신된 경우에 판독 동작이 완료되지 않을 것이다. 대신, 지정된 수의 바이트가 판독된 경우에만 동작이 완료될 것이다. Value가 FALSE이면, 지정된 수의 바이트가 판독되거나, 짧은 패킷이 수신된 경우에 판독 동작이 완료될 것이다. 디폴트는 FALSE이다.

ALLOW_PARTIAL_READS(0x05)

Value가 (0인)FALSE이면, 디바이스가 요청한 것보다 많은 데이터를 리턴한 경우에 판독 요청이 실패할 것이다. Value가 TRUE이면, 여분 데이터는 저장되고, 다음 판독 요청에 대한 데이터의 시작점에서 반환된다. 디폴트는 TRUE이다.

AUTO_FLUSH(0x06)

Value가 (0인)FALSE이고, 디바이스가 요청한 것보다 많은 데이터를 리턴하면, 잔여 데이터는 폐기될 것이다. Value가 TRUE이면, 동작은 ALLOW_PARTIAL_READS의 값에 의존한다. 데이터가 저장되고, 그 후 다음 판독 요청에 대한 데이터의 시작점에서 리턴되거나, 또는 요청이 실패할 것이다. 디폴트는 FALSE이다.

Raw_IO(0x07)

이는 (도 1 내지 도 2의 112와 같은) 사용자 소프트웨어 컴포넌트가 적절한 데이터 처리를 보장하도록 한다. 사용자 소프트웨어 컴포넌트가 제공한 데이터가 부적절한 형식이면, 데이터는 플러시(flush)될 것이다.

10. WinUsb_GetPipePolicy

WinUsb_GetPipePolicy 함수는 특정 파이프(엔드포인트)에 대한 정책을 획득한다. 본 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL __stdcall

WinUsb_GetPipePolicy(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR PipeID,

IN ULONG PolicyType,

IN OUT PULONG ValueLength,

OUT PVOID Value

);

파라미터들

InterfaceHandle

이는 WinUsb_Initialize에 의해 리턴되는 인터페이스 핸들이다.

PipeID

이는 정책을 획득할 파이프의 파이프 식별자이다.

PolicyType

이는 획득할 정책 파라미터를 지정하는 값이다.

ValueLength

이는 Value가 가리키는 버퍼의 길이에 대한 포인터이다. 출력에 있어서, 본 파라미터는 Value 버퍼에 복사된 데이터 길이를 수신한다.

Value

이는 지정된 파이프 정책을 수신한 버퍼에 대한 포인터이다.

리턴 값

11. WinUsb_SetFifoPolicy

WinUsb_SetFifoPolicy 함수는 지정된 파이프(엔드포인트)에 대한 정책을 세팅한다. 본 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL __stdcall

WinUsb_SetFifoPolicy(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR PipeID,

IN ULONG PolicyType,

IN ULONG ValueLength,

IN ULONG_PTR Value

);

파라미터들

InterfaceHandle

이는 WinUsb_Initialize에 의해 리턴되는 인터페이스 핸들이다.

PipeID

이는 정책을 세팅할 파이프의 파이프 식별자이다.

PolicyType

이는 변경할 정책 파라미터를 지정하는 값이다.

ValueLength

Value

이는 PolicyType에 의해 지정된 정책 파라미터에 대한 새로운 값이다.

리턴 값

주석

다음 목록은 가능한 PolicyType 값들을 기술한다.

FIFO_SIZE(0x01)

Value는 FIFO 입력 버퍼의 바이트 단위의 크기이다. 디폴트 값은 16 x MaxPacketSize이다. 이러한 한계에 도달하면, 데이터를 잃게 된다.

NOTIFICATION_THRESHOLD(0x03)

Value는 콜백 함수를 호출하기 전에 FIFO 버퍼에 존재해야하는 바이트 수이다. IGNORE_SHORT_PACKETS가 FALSE이며, 짧은 패킷의 경우에는 무조건 콜백 함수를 호출할 것이다.

12. WinUsb_GetFifoPolicy

WinUsb_GetFifoPolicy 함수는 특정 파이프(엔드포인트)에 대한 정책을 획득한다. 본 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL __stdcall

WinUsb_GetFifoPolicy(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR PipeID,

IN ULONG PolicyType,

IN OUT PULONG ValueLength,

OUT PVOID Value

);

파라미터들

InterfaceHandle

이는 WinUsb_Initialize에 의해 리턴되는 인터페이스 핸들이다.

PipeID

이는 정책을 획득할 파이프의 파이프 식별자이다.

PolicyType

이는 획득할 정책 파라미터를 지정하는 값이다.

ValueLength

Value

이는 지정된 FIFO 정책 파라미터를 수신한 버퍼에 대한 포인터이다.

리턴 값

13. WinUsb_StartFifo

WinUsb_StartFifo 함수는 디바이스로부터 FIFO 버퍼로 데이터를 판독하는 자동 판독 메커니즘을 시작한다. 데이터가 해당 버퍼에 추가되면, 클라이언트에게 데이터의 존재를 알려주는 FifoDataNotification 함수가 호출된다. 그 후, 클라이언트는 FIFO 버퍼로부터 데이터를 판독하기 위한 요청을 발생시킨다. 본 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL __stdcall

WinUsb_StartFifo(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR PipeID,

IN PWINUSB_NOTIFICATION_CALLBACK FifoDataNotification,

IN PVOID FifoDataNotificationContext

);

파라미터들

InterfaceHandle

이는 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

PipeID

이는 영향을 미칠 파이프의 파이프 식별자이다.

FifoDataNotification

이는 통지 임계치(notification threshold)에 도달한 경우에 호출할 선택적인 콜백 함수이다.

FifoDataNotificationContext

이는 FifoDataNotification 콜백 함수에 전달될 선택적인 콘텍스트이다.

리턴 값

주석

PWINUSB_NOTIFICATION_CALLBACK 타입 선언은 다음과 같다:

typedef

VOID

(*PWINUSB_NOTIFICATION_CALLBACK)(

WINUSB_INTERFACE_HANDLE InterfaceHandle,

UCHAR PipeID,

ULONG NotificationType,

PVOID NotifictionParameter,

PVOID Context

);

NotificationType 멤버로서 가능한 한 가지 값은 FifoDataAvailable(0x01)이다. 이 값은 FIFO 버퍼가 NOTIFICATION_THRESHOLD 바이트들의 READFIFO 요청이 즉시 종료되기 위해 충분한 데이터를 가지고 있음을 의미한다. 따라서, NotificationParameter는 무시할 수 있다.

14. WinUsb_StopFifo

WinUsb_StopFifo 함수는 자동 판독 메커니즘을 중단시킨다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL __stdcall

WinUsb_StopFifo(

IN WINUSB_INTERFACE_HANDLE InterfacHandle,

IN UCHAR PipeID

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

PipeID

이것은 영향을 미치는 파이프의 파이프 식별자이다.

리턴 값

이 함수는, 성공적으로 수행되고 구조체를 실장한 경우 TRUE를 리턴한다. 그렇지 않은 경우, 함수는 FALSE를 리턴하며, 로깅된 에러는 GetLastError를 호출함으로써 검색될 수 있다.

15. WinUsb_ReadFifo

WinUsb_ReadFifo 함수는 파이프의 FIFO 버퍼로부터 데이터를 판독한다. USB 패킷 크기는 판독 요청을 위한 전송에 대해 고려되지 않는다는 점에 유의해야 한다. 만약 디바이스가 클라이언트 버퍼에 대해 지나치게 큰 패킷으로 응답한다면, ALLOW_PARTIAL_READS가 TRUE인 경우에는 다음 전송이 시작될 때에 데이터가 추가된다. 만약 ALLOW_PARTIAL_READS가 FALSE라면, 판독 요청은 실패할 것이다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL __stdcall

WinUsb_ReadFifo(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR PipeID,

OUT PUTCHAR Buffer,

IN ULONG BufferLength,

OUT PULONG LengthTransferred,

IN LPOVERLAPPED Overlapped

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

PipeID

이것은 판독될 파이프의 식별자이다.

Buffer

이것은 데이터가 판독되어 저장될 호출자-할당 버퍼(caller-allocated buffer)이다.

BufferLength

이것은, Buffer의 바이트 단위의 길이 또는 판독될 최대 바이트 개수이다.

LengthTransferred

이것은 Buffer에 복사된 실제 바이트 개수를 수신하는 ULONG에 대한 포인터 이다.

Overlapped

이것은 비동기 동작을 위해 사용되는 OVERLAPPED 구조체에 대한 선택적인 포인터(optional pointer)이다. 만약 이 파라미터가 지정되면, 이 함수는 즉시 리턴할 것이며, 동작이 완료된 경우 이벤트가 발송된다.

리턴 값

16. WinUsb_ReadPipe

WinUsb_ReadPipe 함수는 파이프로부터 데이터를 판독한다. USB 패킷 크기는 판독 요청을 위한 전송에 대해 고려되지 않는다는 점에 유의해야 한다. 만약 디바이스가 클라이언트 버퍼에 대해 지나치게 큰 패킷으로 응답한다면, ALLOW_PARTIAL_READS가 TRUE인 경우에는 다음 전송이 시작될 때에 데이터가 추가된다. 만약 ALLOW_PARTIAL_READS가 FALSE라면, 판독 요청은 실패할 것이다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL __stdcall

WinUsb_ReadPipe(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR PipeID,

IN PUTCHAR Buffer,

IN ULONG BufferLength,

OUT PULONG LengthTransferred,

IN LPOVERLAPPED Overlapped

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

PipeID

이것은 판독될 파이프의 식별자이다.

Buffer

이것은 데이터가 판독되어 저장될 호출자-할당 버퍼이다.

BufferLength

이것은, Buffer의 바이트 단위 길이 또는 판독될 최대 바이트 개수이다.

LengthTransferred

이것은 Buffer에 복사된 실제 바이트 개수를 수신하는 ULONG에 대한 포인터이다.

Overlapped

이것은 비동기 동작을 위해 사용되는 OVERLAPPED 구조체에 대한 선택적인 포인터이다. 만약 이 파라미터가 지정되면, 이 함수는 즉시 리턴할 것이며, 동작이 완료된 경우 이벤트가 발송된다.

리턴 값

17. WinUsb_WritePipe

WinUsb_WritePipe 함수는 데이터를 파이프에 기록한다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL __stdcall

WinUsb_WritePipe(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR PipeID,

IN PUTCHAR Buffer,

IN ULONG BufferLength,

OUT PULONG LengthTransferred,

IN LPOVERLAPPED Overlapped

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

PipeID

이것은 기록될 파이프의 식별자이다.

Buffer

이것은 기록될 데이터를 포함하는 호출자-할당 버퍼이다.

BufferLength

이것은 기록될 바이트의 개수이다.

LengthTransferred

이것은 파이프에 기록된 실제 바이트 개수를 수신하는 ULONG에 대한 포인터이다.

Overlapped

리턴 값

18. WinUsb_ControlTransfer

WinUsb_ControlTransfer 함수는 디폴트 컨트롤 디바이스 ID(default control endpoint)를 통해 데이터를 전송한다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL __stdcall

WinUsb_ControlTransfer(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN WINUSB_SETUP_PACKET SetupPacket,

IN PUTCHAR Buffer,

IN ULONG BufferLength,

OUT PULONG LengthTransferred,

IN LPOVERLAPPED Overlapped

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

SetupPacket

이것은 8-바이트의 셋업 패킷이다.

Buffer

이것은 전송할 데이터를 포함하는 호출자-할당 버퍼이다.

BufferLength

이것은 전송할 바이트의 개수이며, 셋업을 포함하지 않는다.

LengthTransferred

이것은 전송된 바이트의 실제 개수를 수신하는 ULONG에 대한 포인터이다.

Overlapped

리턴 값

주석

WINUSB_SETUP_PACKET 구조체 선언은 다음과 같다:

typedef struct _WINUSB_SETUP_PACKET {

UCHAR RequestType;

UCHAR Request;

USHORT Value;

USHORT Index;

USHORT Length;

} WINUSB_SETUP_PACKET, *PWINUSB_SETUP_PACKET;

19. WinUsb_ResetPipe

WinUsb_ResetPipe 함수는 데이터 토글(data toggle)을 리셋시키고, 파이프 상의 스톨 조건(stall condition)을 클리어한다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL __stdcall

WinUsb_ResetPipe(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

In UCHAR PipeID

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

PipeID

이것은 컨트롤 파이프의 식별자이다.

리턴 값

20. WinUsb_AbortPipe

WinUsb_AbortPipe 함수는 파이프에 대한 모든 계류 중인 전송을 취소한다. 이 API를 호출하기 위한 예시적인 메소드는 다음과 같다:

BOOL __stdcall

WinUsb_AbortPipe(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

In UCHAR PipeID

);

파라미터들

InterfaceHandle

이것은 WinUsb_Initialize에 의해 리턴된 인터페이스 핸들이다.

PipeID

이것은 컨트롤 파이프의 식별자이다.

리턴 값

21. WinUsb_FlushPipe

WinUsb_FlushPipe 함수는 클라이언트가 요청한 것보다 많은 데이터를 반환하는 디바이스의 결과로서 저장된 어떠한 데이터도 폐기한다. 이러한 API를 호출하기 위한 예시 메소드는 다음과 같다:

BOOL_stdcall

WinUsb_FlushPipe(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN UCHAR PipeID

);

파라미터들

InterfaceHandle

이는 WinUsb_Initialize에 의해 반환되는 인터페이스 핸들이다.

PipeID

이는 제어 파이프의 식별자이다.

리턴 값

이 함수는 이것이 성공하여 구조체를 실장한 경우에 TRUE를 리턴한다. 그렇지 않으면 이는 FALSE를 리턴하고 로깅된 오류를 GetLastError를 호출함으로써 검색할 수 있다.

전력 관리(Power Management)

도 5는 일반적인 디바이스 드라이버들에서 전력 관리를 제공하기 위한 예시 방법(500)을 도시한다. 일 실시예에서, 방법(500)에 의해 컴퓨팅 시스템(도 6을 참조하여 설명한 것과 같음)은 디바이스들(도 1 내지 4를 참조하여 설명한 것과 같음)이 자신에 부착되어 있는 동안 저전력 상태로 진입할 수 있게 한다.

전력 관리 정책은 부착된 디바이스(들)(502)에 대하여 예컨대 일반적인 USB 사용자-모드 라이브러리(예컨대 도 1의 110)를 통해 정의된다. 전력 정책은 자동 일시 정지가 허용되는지, 디바이스가 자동으로 깨어날 수 있는지, 및/또는 최소 지연 임계치가 디바이스를 일시 정지시키기 위하여 설정되는지에 관한 조항을 포함할 수 있다(이는 WinUsb_SetInterfacePowerPolicy와 같은 예시 API들을 참조하여 더 논의된다).

보다 구체적으로, 자동 일시 정지는 언제 디바이스가 "유휴(idle)" 상태가 되는지를 검출하는 것을 수반할 수 있으며, 이는 일반적인 USB 드라이버(예컨대 도 1 및 도 2의 108)가 전력을 절약하기 위해 디바이스를 일시 정지시키는 시점에서 지정된 시간동안 전송이 일어나지 않았음을 의미할 수 있다. 일 실시예에서, 일반적인 USB 드라이버는 디바이스의 전원이 언제 복귀될 필요가 있는지를 자동으로 검출하고, 이를 적합한 시간에 실시한다.

컴퓨팅 시스템을 자동으로 깨우는 것과 관련하여, 클라이언트(예컨대 도 1 및 도 2의 112)는 일반적인 USB 디바이스 드라이버의 동작을 설정하여 디바이스가 컴퓨팅 시스템을 저전력 상태(예컨대 대기 또는 동면)로부터 깨울 수 있게끔 할 수 있다. 일 실시예에서, 일반적인 USB 디바이스 드라이버는 이러한 기능을 위해 디바이스 및 컴퓨팅 시스템을 준비하는 데 필요한 모든 동작들을 처리한다.

또한, 지연 임계 기간은 일반적인 USB 디바이스 드라이버가 보장할 필요가 있는 시간이 최후의 전송 후 디바이스를 일시 정지시키기에 앞서 경과하는 것을 클라이언트(예컨대 도 1 및 도 2의 112)가 지정할 수 있도록 설정될 수 있다. 따라서, 지연 임계치는 데이터 전송 후의 시간을 지정할 수 있으며, 컴퓨팅 시스템은 데이터 전송 후의 기간이 디바이스가 일시 정지 모드에 진입하기에 앞서 경과하는 것을 기다리게 된다.

일단 일시 정지 모드에 진입하기 위한 조건(들)이 충족되면(예컨대 효력이 있는 전력 정책에 따라)(504), 디바이스는 저전력 상태에 진입한다(506). 이는 디바이스가 부착된 컴퓨팅 시스템이 저전력 상태(508)에 진입(앞서 설명한 바처럼 유선 또는 무선으로)하게 할 수 있다(508).

방법(500)은 복수의 디바이스들이 컴퓨팅 시스템에 부착된 경우에도 본 명세서에서 설명한 일반적인 디바이스 드라이버들이 제공하는 기능을 이용함으로써 전력 절약을 구현할 수 있다. 즉, 일반적인 디바이스 드라이버 구성이 없는 경우, 컴퓨팅 시스템에 부착된 복수의 디바이스들은 동시에 또는 충분한 기간동안 일시 정지 모드에 진입하여 컴퓨팅 시스템에 의한 효율적인 전체 전력 절약이 가능하도록 할 수 없게 된다.

다양한 실시예들에서, 이하의 목록은 전력 관리 상태에 있어서의 동작을 요약해 준다:

● 모든 파이프 핸들, 인터페이스 핸들, 록 및 대체 설정은 전력 관리 이벤트에 걸쳐 보존된다.

● 진행중인 어떠한 전송도 저전력 상태동안 일시 정지되며, 시스템이 동작할 때에 복귀된다. 클라이언트{즉 사용자 소프트웨어 컴포넌트(112)}가 FIFO 버퍼를 이용하는 경우, 이 버퍼는 전력 관리 복귀 후에 재시작된다.

● 디바이스에 특정된 구성이 복구되어야 하는 경우, 클라이언트{즉 사용자 소프트웨어 컴포넌트(112)}는 시스템이 다시 동작하는 경우에 이를 수행해야 한다. 이는 WM_POWERBROADCAST 메시지로부터 결정될 수 있다.

● 클라이언트{즉, 사용자 소프트웨어 컴포넌트(112)}는 WINUSB_SetInterfaceIdle을 호출함으로써 인터페이스가 유휴 상태임을 지시할 수 있으며, 이에 의해 선택적인 일시 정지를 지원할 수 있다. 호출자는 유휴 상태 동안 원격 웨이크업(wakeup)이 가능하도록 지정할 수 있다. 이러한 호출은 직접적인 행위를 수반하는 것은 아니다.

또한, 이하 상세히 설명할 바와 같이, 다른 API들이 전력 관리를 처리하는 데 이용될 수 있으며, 이에 의해 사용자 소프트웨어 컴포넌트가 전력 관리 기능들을 더욱 정교하게 제어할 수 있게 된다.

1. WinUsb_SetInterfacePowerPolicy

WinUsb_SetInterfacePowerPolicy 함수는 디바이스를 위한 전력 정책을 설정한다. 이 API를 호출하기 위한 예시 메소드는 다음과 같다:

BOOL_stdcall

WinUsb_SetInterfacePowerPolicy(

WINUSB_INTERFACE_HANDLE InterfaceHandle,

ULONG PolicyType,

ULONG ValueLength,

ULONG_PTR Value

);

파라미터들

InterfaceHandle

이는 WinUsb_Initialize가 반환한 인터페이스 핸들이다.

PolicyType

이는 정책 파라미터가 변경되도록 지정하는 값이다.

ValueLength

이는 Value가 가리키는 버퍼의 바이트 단위 길이이거나, Value가 버퍼를 가리키지 않는 경우 0이다.

Value

이는 PolicyType이 지정하는 정책 파라미터를 위한 새로운 값이다.

리턴 값

이 함수는 이것이 성공하여 구조체를 실장한 경우에 TRUE를 반환한다. 그렇지 않으면 이는 FALSE를 반환하고 로깅된 오류를 GetLastError를 호출함으로써 검색할 수 있다.

주석

이하의 리스트는 가능한 PolicyType 값들을 기술한다:

AUTO_SUSPEND (0x01)

Value가 TRUE(0이 아님)인 경우, 디바이스는 대기중인 전송이 없는 경우에 일시 정지된다. 디폴트는 TRUE이다.

ENABLE_WAKE (0x02)

디바이스가 WAKE를 지원하는 경우 Value를 TRUE로 설정한다. 디폴트는 FALSE이다.

SUSPEND_DELAY (0x03)

Value는 드라이버가 임의의 전송 후 디바이스를 일시 정지시킬 수 있기에 앞서 대기해야 하는 밀리초 단위의 최소 기간이다. 디폴트는 5초이다.

2. WinUsb_GetInterfacePowerPolicy

WinUSB_GetInterfacePowerPolicy 함수는 디바이스를 위한 전력 정책을 획득한다. 이 API를 호출하기 위한 예시 메소드는 다음과 같다:

BOOL_stdcall

WinUsb_GetInterfacePowerPolicy(

IN WINUSB_INTERFACE_HANDLE InterfaceHandle,

IN ULONG PolicyType,

IN OUT PULONG ValueLength,

OUT PVOID Value

);

파라미터들

InterfaceHandle

이는 WinUsb_Initialize가 반환한 인터페이스 핸들이다.

PolicyType

이는 정책 파라미터가 획득하도록 지정하는 값이다.

ValueLength

이는 Value가 가리키는 버퍼의 길이에 대한 포인터이다. 출력에서, 이 파라미터는 Value 버퍼로 복사된 데이터의 길이를 수신한다.

Value

이는 지정된 전력 정책 값을 수신하는 버퍼에 대한 포인터이다.

리턴 값

3. WinUsb_EnableInterfaceIdle

WinUSB_EnableInterfaceIdle 함수는 운영 체제가 디바이스의 전원을 끌 수 있도록(USB 일시 정지) 인터페이스가 유휴 상태에 있음을 지시한다. 이는 사용자-모드 클라이언트가 선택적인 일시 정지를 어떻게 지원하는 방식이다. 파이프들 중 하나에 대한 임의의 액세스(판독 또는 기록)는 자동으로 인터페이스가 유휴 상태에서 벗어나게 하고, 이에 따라 유휴 상태의 질의가 제공되지 않는다. 이 함수를 호출하는 것은 디바이스가 일시 정지되는 것을 보장하지는 않으며, 단지 디바이스가 현재 USB 일시 정지 상태를 지원할 수 있다는 암시에 불과하다. FIFO 버퍼가 동작하는 경우, 이는 디바이스가 실제로 일시 정지될 때까지 계속 동작한다. 이 API를 호출하는 예시 메소드는 다음과 같다:

BOOL_stdcall

WinUsb_EnableInterfaceIdle(

WINUSB_INTERFACE_HANDLE InterfaceHandle

);

파라미터들

InterfaceHandle

이는 WinUsb_Initialize가 반환한 인터페이스 핸들이다.

리턴 값

4. WinUsb_DisableInterfaceIdle

WinUsb_DisableInterfaceIdle 함수는 디바이스가 일시 정지되는 것 또는 디바이스가 이미 일시 정지된 경우 디바이스를 깨우는 것을 방지한다. 이 API를 호출하는 예시 메소드는 다음과 같다:

BOOL_stdcall

WinUsb_DisableInterfaceIdle(

WINUSB_INTERFACE_HANDLE InterfaceHandle

);

파라미터들

InterfaceHandle

이는 WinUsb_Initialize가 반환한 인터페이스 핸들이다.

리턴 값

이 함수는 이것이 성공하여 구조체를 실장한 경우에 TRUE를 리턴한다. 그렇 지 않으면 이는 FALSE를 리턴하고 로깅된 오류를 GetLastError를 호출함으로써 검색할 수 있다.

보안(SECURITY)

일 실시예에 있어서, 일반적인 디바이스 드라이버(108) 내의 IoResigterDeviceInterface에 의해 생성된 상기(named) 디바이스 객체(device object)를 통해 보안기능이 제공될 수 있다. 보안 특성은 이를 열 수 있는 자를 제한하는 이 기호적인 링크(symbolic link)에 대하여 특정될 수 있다.

이러한 실시예에 있어서, 단 하나의 사용자 소프트웨어 컴포넌트(예를 들어, 112)는 임의의 주어진 시간에 개방되는 링크를 가질 수 있다. 그러므로, 소프트웨어 컴포넌트가 링크를 개방한 경우 소프트웨어 컴포넌트가 실제 핸들(actual handle)을 취득하지 못하는 한 다른 소프트웨어 컴포넌트는 인터페이스에 액세스할 수 없다.

물리적 디바이스를 위한 컨트롤 파이프(control pipe)가 복수의 인터페이스(예를 들어 디바이스가 지원하는 다른 기능)에서 공유될 수 있으므로, 사용자 소프트웨어 컴포넌트는 다른 인터페이스로 컨트롤 명령어를 전송할 수 있다. 이를 구현하기 위해서는 컨트롤 전송에 있어서 어떤 제한사항이 요구될 수 있다. 또한, 기호적인 링크에서의 보안 액세스는 PDO(204)의 보안 특성을 설정함으로써 핸들링될 수 있다.

일반적인 컴퓨팅 환경(GENERAL COMPUTING ENVIRONMENT)

도 6은 여기서 설명하는 기술을 구현하기 위하여 사용될 수 있는 일반적인 컴퓨터 환경(600)을 도시한다. 예를 들어, 컴퓨터 환경(600)은 총칭 디바이스 드라이버(108), 총칭 사용자-모드 라이브러리(110), 및/또는 사용자 소프트웨어 컴포넌트(112)를 포함한 OS를 실행시키는데 사용될 수 있다. 컴퓨터 환경(600)은 컴퓨팅 환경의 예에 불과하며, 컴퓨터 및 네트워크 아키텍처의 사용 또는 기능의 범위를 한정하고자 하는 것은 아니다. 컴퓨터 환경(600)은 예시적인 컴퓨터 환경(600)에 도시된 컴포넌트 중 임의의 하나 또는 이들의 조합과 관련하여 어떠한 종속성 또는 요구사항이 있는 것으로 해석되어서는 안 된다.

컴퓨터 환경(600)은 컴퓨터(602) 형태의 범용 컴퓨팅 디바이스를 포함한다. 컴퓨터(602)의 컴포넌트는 하나 이상의 프로세서 또는 프로세싱 유닛(604)(선택적으로 암호 프로세서(cryptographic processor) 또는 코프로세서(co-processor)를 포함함), 시스템 메모리(606)와, 프로세서(604)를 포함한 다양한 시스템 컴포넌트를 시스템 메모리로 연결하는 시스템 버스(608)를 포함할 수 있으나, 이에 한정되는 것은 아니다.

시스템 버스(608)는 임의의 여러 타입의 버스 구조(bus structures) 중 하나 이상을 나타내며, 이는 메모리 버스 또는 메모리 컨트롤러, 주변 버스, 가속 그래픽 포트(accelerated graphics port), 및 임의의 다양한 버스 아키텍처를 사용하는 프로세서 또는 로컬 버스를 포함한다. 예를 들어, 이러한 아키텍처는 ISA 버스(Industry Standard Architecture bus), 마이크로 채널 아키텍처(Micro Channel Architecture, MCA) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 로컬 버스, 메자닌 버스(Mezzanine bus)라고도 알려진 PCI(Peripheral Component Interconnects) 버스를 포함할 수 있다.

컴퓨터(602)는 전형적으로 다양한 컴퓨터 판독 가능한 매체를 포함한다. 이러한 매체는 컴퓨터(602)에 의하여 액세스 가능한 임의의 이용 가능한 매체일 수 있으며, 휘발성 및 비휘발성 매체, 착탈형(removable) 및 고정형(non-removable) 매체를 모두 포함한다.

시스템 메모리(606)는 랜덤 액세스 메모리(RAM, 610)와 같은 휘발성 메모리 형태, 및/또는 판독 전용 메모리(ROM, 612)와 같은 비휘발성 메모리 형태의 컴퓨터 판독 가능한 매체를 포함한다. 기동(start-up) 시 등에 컴퓨터(602) 내의 엘리먼트간의 정보 전송을 돕는 기초 루틴을 포함한 BIOS(기본 입출력 시스템, 614)는 ROM(612) 내에 저장된다. RAM(610)은 전형적으로 프로세싱 유닛(604)에 즉시 액세스 가능하고 프로세싱 유닛(604)에 의해 현재 동작되는 데이터 및/또는 프로그램 모듈을 포함한다.

또한, 컴퓨터(602)는 다른 착탈형/고정형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 예를 들어, 도 6은 고정형 비휘발성 자기 매체(도시하지 않음)로부터 판독하고 이에 기록하기 위한 하드디스크 드라이브(616), 착탈형 비휘발성 자기 디스크(620)(예를 들어, "플로피 디스크")로부터 판독하고 이에 기록하기 위한 자기 디스크 드라이브(618), CD-ROM, DVD-ROM 또는 다른 광학 매체와 같은 착탈형 비휘발성 광학 디스크(624)로부터 판독하고 이에 기록하기 위한 광학 디스크 드라이브(622)를 도시한다. 하드디스크 드라이브(616), 자기 디스크 드라이브(618), 및 광학 디스크 드라이브(622)는 각각 하나 이상의 데이터 매체 인터페이스 (626)에 의하여 시스템 버스(608)로 접속된다. 또는, 하드디스크 드라이브(616), 자기 디스크 드라이브(618) 및 광학 디스크 드라이브(622)는 하나 이상의 인터페이스(도시하지 않음)에 의하여 시스템 버스(608)에 접속될 수도 있다.

디스크 드라이브 및 이와 관련된 컴퓨터 판독 가능한 매체는 컴퓨터(602)를 위한 컴퓨터 판독 가능한 지시어(instruction), 데이터 구조, 프로그램 모듈 및 다른 데이터의 비휘발성 저장을 제공한다. 예로서는 하드디스크(616), 착탈형 자기 디스크(620) 및 착탈형 광학 디스크(624)를 도시하였지만, 자기 카세트 또는 다른 자기 저장 디바이스, 플래시 메모리 카드, CD-ROM, DVD 또는 다른 광학 스토리지, RAM, ROM, EEPROM(electrically erasable programmable read-only memory) 등과 같이 컴퓨터에 의해 액세스 가능한 데이터를 저장할 수 있는 다른 타입의 컴퓨터 판독 가능한 매체를 사용하여 예시적인 컴퓨팅 시스템 및 환경을 구현할 수 있다.

예를 들어 운영 시스템(626), 하나 이상의 애플리케이션 프로그램(628), 다른 프로그램 모듈(630) 및 프로그램 데이터(628)를 포함하는 임의의 수의 프로그램 모듈이 하드디스크(616), 자기 디스크(620), 광학 디스크(624), ROM(612) 및/또는 RAM(610)에 저장될 수 있다. 이러한 운영 시스템(626), 하나 이상의 애플리케이션 프로그램(628), 다른 프로그램 모듈(630) 및 프로그램 데이터(628)의 각각은 분산 파일 시스템(distributed file system)을 지원하는 상주 컴포넌트(resident component)의 전부 또는 일부를 구현할 수 있다.

사용자는 키보드(634) 및 포인팅 디바이스(636)(예를 들어, "마우스")와 같은 입력 디바이스를 통하여 컴퓨터(602)에 명령어(commands) 및 정보를 입력할 수 있다. 다른 입력 디바이스(368)(구체적으로 도시하지 않음)는 마이크로폰, 조이스틱, 게임 패드, 위성 안테나(satellite dish), 시리얼 포트, 스캐너 등을 포함할 수 있다. 이러한 입력 디바이스 및 다른 입력 디바이스는 시스템 버스(608)에 접속되는 입/출력 인터페이스(640)를 통하여 프로세싱 유닛(604)에 접속되지만, 패러럴 포트(parallel port), 게임 포트 또는 USB(도 1 및 2와 관련하여 설명함)와 같은 다른 인터페이스 및 버스 구조에 의하여 접속될 수도 있다. USB 포트는 카메라, 개인 휴대 정보 단말기(PDA), MP3 디바이스, 비디오 캡쳐 디바이스, 플래시 카드 판독기 등을 컴퓨터 환경(600)에 접속하기 위하여 사용될 수 있다.

모니터(642) 또는 다른 타입의 디스플레이 디바이스도 비디오 어댑터(644)와 같은 인터페이스를 통하여 시스템 버스(608)에 접속될 수 있다. 모니터(642)에 추가하여 다른 출력 주변 디바이스는 입/출력 인터페이스(640)를 통하여 컴퓨터(602)에 접속될 수 있는 스피커(도시하지 않음) 및 프린터(646)와 같은 컴포넌트를 포함할 수 있다.

컴퓨터(602)는 원격 컴퓨팅 디바이스(648)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 사용하여 네트워크화된 환경(networked environment)에서 동작할 수 있다. 예를 들어, 원격 컴퓨팅 디바이스(648)는 퍼스널 컴퓨터, 휴대용 컴퓨터, 서버, 라우터, 네트워크 컴퓨터, 피어 디바이스(peer device) 또는 다른 일반적인 네트워크 노드, 게임 콘솔 등일 수 있다. 원격 컴퓨팅 디바이스(648)는 컴퓨터(602)와 관련하여 설명하는 엘리먼트 및 특성의 대부분 또는 전부를 포함할 수 있는 휴대용 컴퓨터로서 나타내어진다.

컴퓨터(602) 및 원격 컴퓨터(648) 간의 논리적인 접속은 근거리 통신망(LAN, 650) 및 광대역 통신망(WAN, 652)으로서 나타내었다. 이러한 네트워킹 환경은 사무실, 기업내(enterprise-wide) 컴퓨터 네트워크, 인트라넷, 인터넷에서 일반적인 것이다.

LAN 네트워킹 환경에서 구현될 경우, 컴퓨터(602)는 네트워크 인터페이스 또는 어댑터(654)를 통하여 로컬 네트워크(650)에 접속된다. WAN 네트워킹 환경에서 구현될 경우, 컴퓨터(602)는 전형적으로 모뎀(656) 또는 광대역 네트워크(652)를 통해 통신하기 위한 다른 수단을 포함한다. 모뎀은 컴퓨터(602)의 내부 또는 외부에 있을 수 있는데, 이는 입/출력 인터페이스(640) 또는 다른 적절한 메커니즘을 통하여 시스템 버스(608)에 접속될 수 있다. 설명한 네트워크 접속은 예시적인 것이며 컴퓨터(602 및 648) 간의 통신 링크를 설정하기 위한 다른 수단이 사용될 수 있다.

컴퓨팅 환경(600)에 도시된 것과 같은 네트워크화된 환경에 있어서, 컴퓨터(602)와 관련하여 설명한 프로그램 모듈 또는 그 일부는 원격 메모리 저장 디바이스에 저장될 수 있다. 예를 들어, 원격 애플리케이션 프로그램(658)이 원격 컴퓨터(648)의 메모리 디바이스에 상주한다. 설명을 위하여 애플리케이션 프로그램 및 운영 시스템과 같은 다른 실행 가능한 프로그램 컴포넌트는 여기서 단순한 블록으로 도시하였지만, 이러한 프로그램 및 컴포넌트는 종종 컴퓨팅 디바이스(602)의 다른 저장 컴포넌트에 상주하고, 컴퓨터의 데이터 프로세서(들)에 의해 실행된다.

다양한 모듈 및 기술은, 프로그램 모듈과 같이 하나 이상의 컴퓨터 또는 다 른 디바이스에 의하여 실행되는 컴퓨터 실행 가능한 지시어에 대한 일반적인 내용으로 설명될 수 있다. 일반적으로 프로그램 모듈은 특정 작업을 수행하거나 특정 추상적 데이터 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트 데이터 구조 등을 포함한다. 일반적으로 프로그램 모듈의 기능은 다양한 구현예에 있어서 원하는 대로 조합되거나 분산될 수 있다.

이러한 모듈 및 기술이 구현된 것(implementations)은 여러 형태의 컴퓨터 판독 가능한 매체에 저장되거나 이러한 매체를 통해 전송될 수 있다. 컴퓨터 판독 가능한 매체는 컴퓨터에 의하여 액세스될 수 있는 임의의 이용 가능한 매체일 수 있다. 예를 들어, 컴퓨터 판독 가능한 매체는 "컴퓨터 저장 매체(computer storage media)" 및 "통신 매체(communications media)"를 포함할 수 있으나, 이에 한정되는 것은 아니다.

"컴퓨터 저장 매체"는 컴퓨터 판독 가능한 지시어, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보를 저장하기 위한 임의의 방법 또는 기술에서 구현될 수 있는 휘발성 및 비휘발성, 착탈형 및 고정형 매체를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD 또는 다른 광학 스토리지, 자기 카세트, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 저장 디바이스, 또는 컴퓨터에 의하여 액세스 가능하고 원하는 정보를 저장하기 위하여 사용될 수 있는 임의의 다른 매체를 포함하지만, 이에 한정되는 것은 아니다.

"통신 매체"는 전형적으로 컴퓨터 판독 가능한 지시어, 데이터 구조, 컴퓨터 모듈 또는 캐리어파(carrier wave)나 다른 전송 메커니즘과 같이 변조된 데이터 신호에서의 기타 데이터를 포함한다. 통신 매체는 또한 임의의 정보 전달 매체(information delivery media)를 포함한다. "변조된 데이터 신호"라는 용어는 하나 이상의 특성 세트를 갖고 신호에 정보를 인코딩하는 방식으로 변형된 신호를 의미한다. 예를 들어, 통신 매체는 유선 네트워크 또는 직접 배선(direct-wired) 접속과 같은 유선 매체, 탄성파, 무선 주파수(RF), 적외선, WI-Fi, 셀룰러, 블루투스 가능형, 또는 기타 무선 매체와 같은 무선 매체를 포함할 수 있지만, 이에 한정되는 것은 아니다. 상술한 것들의 임의의 조합도 컴퓨터 판독 가능한 매체에 포함된다.

일 실시예에 있어서, 하드웨어 디바이스는 (도 1 및 2와 관련하여 설명한) 일반적인 컴퓨팅 환경(600)의 컴포넌트와 연결된 임의의 디바이스일 수 있으며, 하드웨어 디바이스의 정보에 액세스하게 된다. 또한, 하드웨어 디바이스는 일반적인 컴퓨터 환경(600)의 주변 디바이스(마우스(636), 키보드(634), 프린터(646) 등)일 수 있다.

결론

본 발명에 대하여 구조적 특징 및/또는 방법적 동작을 특정한 용어로서 설명하였지만, 첨부된 청구범위에서 규정되는 본 발명은 이상에서 설명한 특정한 특징 및 동작으로 반드시 한정되는 것은 아니다. 예를 들어, 여기서 설명한 기술은 유선 또는 무선 통신 채널{블루투스, SCSI(small computer system interface) 등}에 적용될 수 있다. 따라서, 특정한 특징 및 동작은 청구된 본 발명을 구현하는 예시적인 형태로서 개시되는 것이다.

Claims

디바이스의 플러그-인 이벤트(plug-in event)에 응답하여 커널-모드 총칭 디바이스 드라이버(kernel-mode generic device driver)를 로드하는 단계; 및

상기 총칭 디바이스 드라이버에 통신가능하도록 연결되어 있는 총칭 사용자-모드 라이브러리(generic user-mode library)에 의해 제공되는 복수의 루틴들을 사용함으로써, 사용자 소프트웨어 컴포넌트가 상기 디바이스에 액세스하는 단계

를 포함하며,

개별적인 총칭 디바이스 드라이버가 각각의 플러그-인 디바이스에 대하여 또는 상기 디바이스에 의해 지원되는 각각의 기능에 대하여 로드되는 방법.
제1항에 있어서, 상기 복수의 루틴들은 애플리케이션 프로그래밍 인터페이스들(application programming interfaces; APIs)로서 구현되는 방법.
제1항에 있어서, 상기 디바이스는 범용 직렬 버스(universal serial bus; USB) 디바이스인 방법.
제1항에 있어서, 상기 플러그-인 이벤트는 플러그 앤 플래이(plug and play; PNP) 모듈에 의해 검출되는 방법.
제1항에 있어서, 상기 플러그-인된 디바이스에 해당하는 추출된 디바이스 ID에 대응하는 디바이스 드라이버를 로드하는 단계를 더 포함하며, 상기 총칭 디바이스 드라이버는 상기 로드된 디바이스 드라이버와 상기 사용자 소프트웨어 컴포넌트 간의 통신을 촉진시키는 방법.
제5항에 있어서,상기 디바이스 ID는 데이터 통신 버스를 통해 상기 플러그-인된 디바이스에 연결된 코어 스택(core stack)에 의해 추출되는 방법.
플러그-인 이벤트에 응답하여 디바이스 ID를 추출하는 단계;

상기 추출된 디바이스 ID에 해당하는 디바이스 드라이버를 로드하는 단계;

상기 로드된 디바이스 드라이버와 사용자 소프트웨어 컴포넌트 간의 통신을 촉진시키기 위해 총칭 디바이스 드라이버를 로드하는 단계

를 포함하는 방법.
제7항에 있어서, 개별적인 총칭 디바이스 드라이버가 각각의 디바이스 ID에 대하여 또는 상기 디바이스 ID에 해당하는 디바이스에 의해 지원되는 각각의 기능에 대하여 로드되는 방법.
제7항에 있어서, 상기 디바이스 ID는 범용 직렬 버스(USB) 디바이스를 식별하는 방법.
제7항에 있어서, 상기 추출하는 단계는 코어 스택에 의해 수행되는 방법.
제7항에 있어서, 상기 추출하는 단계는 코어 스택에 의해 수행되며, 상기 코어 스택은 복수의 디바이스들과 통신하기 위해 데이터 통신 버스에 연결되는 방법.
제7항에 있어서, 상기 추출하는 단계는 코어 스택에 의해 수행되며, 적어도 하나의 사용자 소프트웨어 컴포넌트가 상기 코어 스택에 연결된 허브를 통하여 복수의 디바이스들과 통신하는 방법.
제7항에 있어서, 상기 총칭 디바이스 드라이버는 커널 모드에서 로드되는 방법.
제7항에 있어서, 상기 사용자 소프트웨어 컴포넌트는 사용자 모드에서 상주하는 방법.
제7항에 있어서, 상기 플러그-인 이벤트는 플러그 앤 플래에(PNP) 모듈에 의해 검출되는 방법.
제7항에 있어서, 상기 플러그-인 이벤트는 플러그 앤 플래에(PNP) 모듈에 의 해 검출되며, 상기 PNP 모듈은 상기 추출된 디바이스 ID를 상기 디바이스 드라이버로 매치시키는 방법.
제7항에 있어서, 상기 추출된 디바이스 ID에 해당하는 고유 ID(unique ID)를 등록하는 단계를 더 포함하는 방법.
제7항에 있어서, 상기 추출된 디바이스 ID에 해당하는 디바이스에 액세스하는 단계를 더 포함하는 방법.
제7항에 있어서, 상기 사용자 소프트웨어 컴포넌트가 총칭 사용자-모드 라이브러리를 통해 상기 총칭 디바이스 드라이버와 통신하는 단계를 더 포함하는 방법.
제7항에 있어서, 상기 사용자 소프트웨어 컴포넌트가 총칭 사용자-모드 라이브러리를 통해 상기 총칭 디바이스 드라이버와 통신하는 단계를 더 포함하며, 상기 사용자-모드 라이브러리는 상기 디바이스 ID에 해당하는 디바이스와의 통신을 촉진시키기 위한 복수의 루틴들을 포함하는 방법.
제20항에 있어서, 상기 루틴들은 애플리케이션 프로그래밍 인터페이스들로서 구현되는 방법.
컴퓨팅 디바이스; 및

상기 컴퓨팅 디바이스에 연결된 디바이스

를 포함하며,

커널-모드 총칭 디바이스 드라이버가 상기 디바이스를 상기 컴퓨팅 디바이스에 연결하는 것에 응답하여 로드되고, 사용자 소프트웨어 컴포넌트가 상기 총칭 디바이스 드라이버에 통신가능하도록 연결되어 있는 총칭 사용자-모드 라이브러리에 의해 제공되는 복수의 루틴들을 사용하여 상기 디바이스를 액세스하며, 개별적인 총칭 디바이스 드라이버가 각각의 디바이스에 대하여 또는 상기 디바이스에 의해 지원되는 각각의 기능에 대하여 로드되는 장치.
제22항에 있어서, 상기 복수의 루틴들은 애플리케이션 프로그래밍 인터페이스들로서 구현되는 장치.
제22항에 있어서, 상기 디바이스는 범용 직렬 버스(USB) 디바이스인 장치.
명령어들을 저장하고 있는 하나 이상의 컴퓨터-판독가능한 매체에 있어서,

상기 명령어들은, 실행될 경우,

디바이스의 플러그-인 이벤트에 응답하여 커널-모드 총칭 디바이스 드라이버를 로드하는 단계; 및

상기 총칭 디바이스 드라이버에 통신가능하도록 연결되어 있는 총칭 사용자- 모드 라이브러리에 의해 제공되는 복수의 루틴들을 사용함으로써, 사용자 소프트웨어 컴포넌트가 상기 디바이스에 액세스하는 단계

를 포함하는 동작들을 머신이 수행하도록 지시하며,

개별적인 총칭 디바이스 드라이버가 각각의 플러그-인 디바이스에 대하여 또는 상기 디바이스에 의해 지원되는 각각의 기능에 대하여 로드되는 하나 이상의 컴퓨터-판독가능한 매체.
제25항에 있어서, 상기 복수의 루틴들은 애플리케이션 프로그래밍 인터페이스들로서 구현되는 하나 이상의 컴퓨터-판독가능한 매체.
제25항에 있어서, 상기 디바이스는 범용 직렬 버스(USB) 디바이스인 하나 이상의 컴퓨터-판독가능한 매체.
제25항에 있어서, 상기 플러그-인 이벤트는 플러그 앤 플래이 모듈에 의해 검출되는 하나 이상의 컴퓨터-판독가능한 매체.
제25항에 있어서, 상기 플러그-인된 디바이스에 해당하는 추출된 디바이스 ID에 대응하는 디바이스 드라이버를 로드하는 단계를 더 포함하며, 상기 총칭 디바이스 드라이버는 상기 로드된 디바이스 드라이버와 상기 사용자 소프트웨어 컴포넌트 간의 통신을 촉진시키는 하나 이상의 컴퓨터-판독가능한 매체.