Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58

[Doug Ledford <dledford@redhat.com>]

On Fri, Jan 24, 2003 at 10:34:11AM -0500, Alan Stern wrote:
> On Thu, 23 Jan 2003, Matthew Dharm wrote:
> 
> > What I want:
> > 
> > I want to be able to free resources associated with a device within a
> > finite (and well bounded) amount of time after I am notified that the
> > device is gone.
> > 
> > I want to be able to inform the SCSI mid-layer, which will then inform
> > higher layers, that the device is gone.  This is so that all may deal with
> > this however they want.  I really don't care who does what, as long as we
> > don't crash.  This implies that all block-type drivers will need to become
> > hotplug aware, or the SCSI mid-layer will have to fake command failures.
> > 
> > I want to be able to do as little command-trickery as possible.  If I have
> > to do it, then that means the next hotplug-capable LLDD must do it also.
> > Duplication of code is bad -- it should all be handled in the mid-layer.
> 
> Matt's current proposed patch has the USB LLDD calling
> scsi_unregister_host()  (because the device is respresented as an emulated
> host adapter) when it learns that the device is gone.  Provided that
> routine doesn't block for very long, provided it handles all the details
> of hotplug notifications, and provided it guarantees that after it returns
> there will be no more calls to the emulated adapter,

There is no such guarantee of this.  Last I checked, 
scsi_unregister_host() can fail if devices are busy.  In fact, I would say 
that's exactly what happened on my system when I unplugged a USB2.0 CD-ROM 
that was in use.  The USB stack called this code, it failed due to busy, 
USB stack didn't care and blew state away, I knew have a permanent CD-ROM 
device that I can no longer clean up and I had to reboot my machine.

> I don't see any
> problem.  The LLDD can go ahead and remove all records of the former
> device, secure in the knowledge that all pointers to data structures and
> entry points have been erased.
> 
> Isn't this exactly what everyone has been asking for and debating about?
> 
> Alan Stern
> 

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606