Bus Drivers (Windows CE 5.0)
A bus driver is any software that loads drivers. Bus drivers have one or more of these responsibilities:
Managing physical busses, such as PC Card, USB, or PCI.
Loading drivers on a physical bus that the bus driver does not directly manage.
An example is the Bus Enumerator, which is a bus driver that loads built-in drivers and PCI bus drivers.
Calling ActivateDeviceEx directly to load a device driver.
The loaded device driver might manage hardware indirectly through another device driver.
To allow access to a device driver with CreateFile, bus drivers should provide Device Manager with enough information to create bus-relative names and enable device handles. They should also provide enough information to identify themselves to drivers and applications for bus control operations. A bus driver can specify a bus-relative name for the driver, but for drivers and applications to be able to access the bus driver for bus control operations, the bus driver must expose a stream interface. The $bus namespace provides a way to perform operations on a device that are different from typical device operations. By controlling access to the $bus namespace, you can also provide security for your system.
To enable access to a driver that uses the $bus namespace
Advertise the DMCLASS_PROTECTEDBUSNAMESPACE GUID in the driver's IClass registry key.
If the driver does not advertise DMCLASS_PROTECTEDBUSNAMESPACE, Device Manager cannot know that the driver is able to differentiate between normal access and system access to the device. DMCLASS_PROTECTEDBUSNAMESPACE must be associated with the driver's $bus interface.
If the driver advertises the DMCLASS_PROTECTEDBUSNAMESPACE interface, the driver's XXX_Open (Device Manager) entry point is invoked with the DEVACCESS_BUSNAMESPACE bit set in the dwAccess parameter. The driver must keep track of which handles were opened with this bit set so that it can accept or reject IOCTLs and other operations appropriately.
Even if the driver does not advertise DMCLASS_PROTECTEDBUSNAMESPACE, its $bus name is still useful for communicating with the driver's parent bus driver for services such as loading, unloading, and power management.
Expose the $bus mount point by adding
=%bafter the IClass registry key value.The IClass registry key value for the driver must have
=%bafter the IClass registry value. The following registry key example shows where to place=%b."IClass"=multi_sz:"{B3CC6EBA-5507-4196-8E41-2BF42E4A47C9}=%b","{6F40791D-300E-44E4-BC38-E0E63CA8375C}=%b"For more information about mount points and device file names, see Device File Names.
Bus Driver Naming Conventions
Bus drivers provide subordinate drivers with a bus name for themselves and a bus name for the newly loaded driver. Generally, bus names should be derived from the bus type, bus number, and other bus specific identifiers such as the device number and function number. The bus driver naming convention assumes that all busses of a particular type are uniquely numbered. When this combination of identifiers is unique, no name collisions occur. For example, different invocations of the Bus Enumerator should be considered different busses and assigned different bus numbers.
Bus numbers are compatible with the INTERFACE_TYPE enumeration. You can add new identifiers for your hardware.
In general, bus names relate to the underlying bus structure. This simplifies the system structure if an application enumerates device drivers on a bus. Bus names differ from stream interface names because not all device drivers expose a stream interface to applications. However, bus names do have to relate to the underlying bus. For example, applications might load device drivers directly by calling ActivateDeviceEx. These applications might not expose a bus interface themselves, but the device driver that the application loaded might expose a bus interface.
For drivers that an application loads, the driver's stream interface name is used to generate a unique bus name. For example, if an application loads "COM1:" or "\$device\COM1", its bus name would be "\$bus\COM1". This is a safe approach because stream interface names are unique throughout the system.
For information about device file names, see Device File Names.
Bus Driver Registry Entries
Device Manager associates bus information with the driver's fsdev_t structure, which is internal to Device Manager. The following table shows the information that bus drivers place in the Active registry key.
| Registry subkey | Description |
|---|---|
| BusDriver | Bus name of the bus driver. "\$bus" is assumed. An example value is "PCI_0_1_0". |
| BusName | Bus name of the driver that is loading. An example value is "PCMCIA_0_1_1". Different busses might structure names differently. For example, USB HID devices might structure this as "HID_interface_collection". |
For information about Device Manager registry keys, see Device Manager Registry Keys.
Bus Driver Power Callbacks
Bus driver ISTs do not have a chance to unload drivers in order to prevent a power callback invocation. This is because threads are not running during power callbacks. As with installable ISRs, power callbacks might attempt to access missing devices when the hardware resumes. To prevent power callbacks from accessing missing devices, the device driver on the parent bus can invoke IOCTL_BUS_IS_CHILD_REMOVED to determine whether its device is missing or not. Power callbacks can invoke this IOCTL. For more information about this IOCTL and other related IOCTLs, see CEDDK Dynamic-Link Library Bus Access IOCTLs.
For information about suspend and resume power callbacks, see Suspend and Resume Power Callbacks.
See Also
CEDDK Dynamic-Link Library Bus Access Reference
Send Feedback on this topic to the authors