Tim Newsham wrote: > > > On Wed, Aug 26, 2009 at 12:10 PM, Tim Roberts <timr@xxxxxxxxx > <mailto:timr@xxxxxxxxx>> wrote: > > However, one way to do what you ask is to make your "other device" > into > a bus driver. When it is ready to have audio services available, you > call IoInvalidateDeviceRelations, which tells PnP to ask your driver > about its child devices. You report the PnP ID for your audio device. > The system will load your audio device, and it will start to run. > > > ahh, thank you. I'll look into this. > > > This is exactly what the USB bus driver does when a device plugs and > unplugs. And, really, it's not that hard to do. > > > Would this be suitable for two devices that are cooperating with each > other (ie. in a master/slave relationship, akin to pseudo-ttys in > unix)? If so, how would I establish a relationship between the master > device (who would be playing the bus driver, I guess) and the > dynamically created slave device that gets loaded when demanded by the > master? I believe that's exactly what I described above. Think of USB as a model. The USB bus driver notices that a new USB device has plugged in. It builds a plug-and-play ID from the device's descriptors, and exposes it through the bus relations, as I described above. Plug-and-play finds the driver in its INF files based on the device ID, the driver is loaded, and everybody is happy. When the device unplugs, the USB bus driver again notifies that its bus relations have changed, and this time plug-and-play starts the removal process on the upper level driver. I think you're talking about the exact same model. Note that you can make the plug-and-play ID be whatever you want. USB happens to use USB\VID_xxxx&PID_xxxx, but that's just a convention. You could have NEWSHAM\AUDIO, for example. -- Tim Roberts, timr@xxxxxxxxx Providenza & Boekelheide, Inc.