Seems to me that there lack of some background introduction for WUSB. I just wrote a blog about WUSB association, it is offering the background info to this issue. Please take a look at: http://blogs.sun.com/colin/entry/association_the_difference_between_usb
And, to be clear, the implementation for supporting WUSB on Solaris comform to the existing usba(7D) framework on Solaris and also devfsadm framework. WUSB device enumeration is the same as USB on Solaris. The difference is "Association" which is a new concept for wireless USB only. It is discussed in detail in the above link. Thanks, Colin Darren J Moffat : > James Carlson wrote: > >> As a way to illustrate the point: suppose we had a new kind of SCSI >> drive that included encryption. Suppose that drive required new >> commands when first connected in order to establish the key in use >> (the "security relationship" between the drive and host). Would we >> need or want a new daemon to handle that? Or would it more naturally >> be an extension of the existing devices framework? >> > > Thats a good example and one I've actually been doing some thinking on. > I think actually it might be a yes to both. We might need a new > daemon to do some key management tasks but we would certainly be > plugging into the existing devices framework. > > >> What I'm concerned about here is that having a separate daemon to >> manage a group of devices will likely lead to even more confusion in >> the whole device allocation and permissions area. >> > > I agree with Jim here in general. > > I would have expected the WUSB to be adding a plugin to > /usr/lib/devfsadm/linkmod/ > > The really important thing here is to make sure that all the existing > frameworks continue to work since this is really a transport layer > change. Compare this to adding IPsec below TCP, applications didn't > have to change and IPsec is part of IP. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/security-discuss/attachments/20080602/7c91debf/attachment.html>
