On Sun, Dec 19, 2010 at 05:02:54AM +0200, Paul Irofti wrote:
quoted text
> 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.

quoted text
> 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.

quoted text
> 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.

quoted text
> Otherwise it would sure get rid of a lot of redundant code in dev/usb/*.

I don't get what you're saying here.

quoted text
> usbd_set_dying(dev, flag)? Don't know.

-- 
jakemsr@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org