Colin Zou wrote:
> Let me explain this in detail. Take Cable Association as an example, the
> whole association process is as following:
>
> 1. user plug the WUSB device to a usb port on the PC box.
> 2. the Soalris USB framework (usba(7D) and ehci(7D)) gets the device
> plug event and enumerates the device as a wired USB device.
> 3. usba attach the wusb_ca driver to the device. wusb_ca driver is a
> newly introduced driver for Cable Association only. It is a normal wired
> USB driver developed on wired USB driver API, fully compliant to Solaris
> USB framework.
> 4. User run wusbadm tool to specify with which WUSB host the device
> should be associated.
> 5. wusbadm tool sends a request to wusbd, who will then open the device
> node created by wusb_ca USB driver.
> 6. wusbd talk to the device via wusb_ca driver to create a CC. It then
> store the CC to CC database in file system, in the mean while, it loads
> the CC to the WUSB host driver.
> 7. wusbd then complete the association request from wusbadm tool.
> 8. Association is done. User then unplug the device. wusba_ca driver is
> then dettached.
>
> After the above is done, user can then turn on the device radio to
> connect the WUSB device with host over air. The subsequent wireless
> enumeration is the same as wired USB. A newly introduced WUSB host
> driver (e.g., whci) is developer on the existing Solaris USB framework
> (usba). whci driver gets the device radio signal and consider it as a
> device plug event. It passes the event to usba framework module, the
> latter then load an existing USB device driver (e.g. usbprn(7D) if the
> device is a WUSB printer) to attach to the WUSB device.
>
> If user reboot the system, wusbd daemon will load the CCs stored in the
> CC database to WUSB host driver instances. So that WUSB host can be
> ready to connect the associated devices.
>
> Please note that, it is necessary to have a daemon (wusbd) because the
> daemon can load CCs to WUSB host drivers automatically after system
> reboot. Users want the WUSB device just work after each reboot, instead
> of manually running a tool to load CCs.
It seems that the functionality of wusbd is triggered in two cases:
1) By an explicit request from wusbadm, during the initial WUSB context
creation process.
2) Automatically at bootup, to load the CC's into host drivers.
So, is a new daemon really needed? It seems that the functions of
wusbd used in (1) above could be implemented in the wusbadm program
itself, and (2) above could be accomplished by a transient SMF service
that invokes wusbadm again with correct options. I think the coreadm
service (svc:/system/coreadm:default) is a good example of this model.
--Nathan
