加载中...

首先，我们来了解一下USB相关的驱动架构，在USB驱动家族里，包括以下几个部分：

１、Miniport驱动，这其中又包括usbuhci.sys, usbohci.sys或usbehci.sys模块，这些模块是不同规范的USB主控制器驱动程序，其中UHCI和OHCI是全/低速USB EHCI主控制器，ehci则是全/高速USB主控制器。

２、HUB驱动，该部分功能又usbhub.sys来完成，这个大家都比较了解，具体我就不多说了。

３、功能驱动，对应不同的USB功能设备，都有不同的功能驱动，比如：USB摄像头，则由usbvideo来完成（当然你也可以使用自己特有的功能驱动代替）。

４、另外还包括一些辅助性模块，如usbport.sys,usbhid.sys等，usbport是与具体USB功能设备无关的HC和HUB功能设计的包装，提供一些公用的函数供USB相关的驱动程序使用，usbhid则是完成hid类相关的功能。

５、在整个驱动的体系结构中，还可存在的就是过滤驱动，他们可以依存于miniport，hub以及功能驱动而存在，这里不考虑由于Hook等原因而介入的驱动，在以下的讨论中，filter驱动也将被忽略。

从以上结构看，我们不难想到，整个驱动的启动过程应该是这样的：

“Miniport”驱动通过调用usbport，建立了最基本的与USB硬件通信的底层服务（说到这里，我要强调一个概念，按Microsoft的规范，所谓“底层”是靠近硬件的而不是靠近应用，之所以提出来，是因为有经常听到一些做驱动开发的朋友弄错，尤其是新手），然后再是hub驱动和类相关的驱动的启动，最后则是功能驱动。

说了这么多，还没有切入正题，其实说到这里，该怎么做，善于思考的朋友就已经有了想法，没错——你的想法是正确的，对于再生USB设备这一端（以下称为“客户端”），我们可以在功能驱动之下构建自己的虚拟USB总线驱动，让远端的USB设备都挂入到功能驱动都接入到我们的驱动中来，我们的驱动要做的最为重要的事情是将所有的请求挂起，并将相关信息打包，发送到网络的另一端，让远端的程序与实际的USB设备通信，然后再将返回的数据回送到客户端，客户端驱动接收到反馈后完成相应的请求。

而对于远端的服务端，其主要的工作是完成网络来的请求，并将请求反馈到客户端。