On Sun, Dec 19, 2010 at 05:02:54AM +0200, Paul Irofti wrote: > On Sat, Dec 18, 2010 at 11:11:35PM +0000, Jacob Meuser wrote: > > this adds activate functions for drivers that don't have them. also > > add usbd_deactivate() in DVACT_DEACTIVATE for drivers that do have > > activate functions but don't have any dying flag. > > > > ok? > > About this interface, I looked around in the code and it seems to be > used mostly in activate functions and in failure cases inside attach.
yes, it's used to set the driver's dying flag. those are the most common places a driver would be marked as dying. maybe also in an interrupt handler. > My question is if its not better to make usbd_deactivate() a function > similar to an activate() one. That way we can just add something like > ubdi_activate in the cfattach instead of a wrapper to it in each driver. hmm. perhaps usbd_deactivate() is not the best name. > I don't know what the plan is for usbd_deactivate thus what I'm > proposing might not make sense. Just a thought. currently it is just a wrapper for setting the dying flag in the driver's usbd_device. maybe it will do other things, but probably not. the pupose of setting the dying flag in the usbd_device is so that this flag can be checked in generic stack functions, because the almost always have access to the usbd_device. if there were just the dying flag in the softc, that isn't available outside the driver. > Otherwise it would sure get rid of a lot of redundant code in dev/usb/*. I don't get what you're saying here. > usbd_set_dying(dev, flag)? Don't know. -- [email protected] SDF Public Access UNIX System - http://sdf.lonestar.org
