Lei Chen writes: > James Carlson wrote: > > Is this something separate from devfsadmd? Should it be? > > > In fact, this daemon is used to handle wireless USB device connection > context, while the devfsadmd manages reconfiguration and device dynamic > events. The new daemon needs to interact with WUSB host to setup a > wireless USB device's connection context. The interactions between > daemon and host are through ioctl.
Is this different from regular USB? How so? I suspect I'm missing some background. I would have expected that, as part of managing the relationship between the wireless USB device and the system, devfsadmd would need to interact with the wireless subsystem and create/destroy nodes on the fly, just as it does for all other dynamic subsystems. Have you talked this over with the device driver folks? (Not sure who they are since Shudong left ... but they have to exist somewhere.) > > In fact, the device node doesn't even have to exist at all for > > ioctl(2) to work correctly, and I see nothing that requires write > > permissions in order to do ioctls. > > > > Am I missing something? Have you tried this and failed? > > > Thank you for the reminding. I had taken it for granted that ioctl needs > write permission. Yes, as long as the user can open the device even only > with O_RDONLY mode, the ioclt can also be done on it. This might be an > issue for a wireless USB host device. The drv_priv(9F) should be used to > check application's privilege to prevent any user with only read > permissions from stopping a host device. Yes; that seems reasonable. (Assuming that the device node permissions are correct.) -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
