Johannes Erdfelt wrote:
> On Fri, May 04, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > Driver disconnect() routines need to unlink ALL urbs as well as
> > > > make sure that no other driver entries (file operations, say) will
> > > > ever try to use that device again (even while unlinking proceeds).
> > >
> > > Then I hope that disconnect() is not called on an irq!
> >
> > Only in uncommon error recovery situations, AFAIK. That's is a
> > good reason to use async unlink in disconnect() though.
>
> disconnect is guaranteed to only happen in a process context (khubd,
> rmmod, etc)
>
> > > ... But if not, then it seems that while it's out,
> > > disconnect() might get called. When the process runs again, how will it know
> > > not to use that device?
> >
> > The driver has its own record for each device, tracking opens and
> > doing whatever other magic it needs. There's also the usb_device
> > pointer.
>
> You can always look at other drivers to see what they do.
>
> > What disconnect() means is: as of this instant, you can't depend on
> > being able to do I/O with this device any more. And when that
> > disconnect() returns, the pointer becomes invalid/unusable.
>
> Not exactly true. With the reference counting, the pointer can still be
> valid. It usually not usable tho since the device is gone now.
>
> > So disconnect() should clear the usb_device pointer in the driver's
> > record. That'd be one way that all other execution contexts in
> > the driver (timer, sleeping process/thread, etc) would know that
> > particular device is disconnected. The driver would free its own
> > record of device state when the last context stopped using it.
>
> Or take advantage of the reference counting.
>
Now this is getting interesting. Let me offer an example and tell me what you
think. In general, here's the question:
if (DEV_STILL_VALID(dev)) {
/* somebody else gets scheduled and calls disconnect() here */
USE_DEV();
}
Wether the hypothetical DEV_STILL_VALID() tested a pointer or used reference
counting doesn't seem to matter offhand. Do I have to treat all such sections as
critical sections, and disable ints? Or is there a lock associated with the dev
struct I can hold until done?
Sorry if these are dumb questions.
Regards,
--gmcnutt
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
