So, was any of this ever implemented?  As far as I can tell, the required
changes were:

(o) addition of scsi_schedule_host_removal() (possibly optional)
(o) implementation of scsi_set_device_offline() (possibly optional)
(o) change the behavior of the 'hotplug initialization model' to call my
release function

Matt

On Fri, Jan 24, 2003 at 08:07:29PM -0500, Doug Ledford wrote:
> On Fri, Jan 24, 2003 at 04:45:53PM -0800, Matthew Dharm wrote:
> > Okay... so what do I do if it fails?  Sleep for a while and try again
> > later?  Wait on a flag somewhere?
> 
> Well, the better option is what I think we are working on.  Instead of
> trying to remove the host completely, just unhook it from the USB stuff,
> then call the set_scsi_device_offline(), then send back any outstanding
> commands via scsi_done(), then possibly call the
> scsi_schedule_host_removal() if Mike adds that function.  Then return.  
> Don't to anything else.  Take all the remaining code you would normally
> run at this point and put it into a function in your source called
> usb_release() and in your Scsi_Host_Template struct that you pass to the
> scsi layer, init the release pointer with the address of your
> usb_release() routine.  That way, the scsi layer can do what it's best at,
> taking care of the clean up details we've been talking about, and when
> it's all done, it will call your usb_release() routine with a single
> argument of the host struct you are wanting released.  At that point, you
> can do all the freeing you would have done in that khubd loop (at least I
> think that's the context you are doing the freeing from now) and know for
> a fact that not only are you freeing everything, but so is the scsi mid
> layer.  I think this will solve all the issues you've had, because this
> *won't* leak, it won't block your other actions, and it lets the scsi
> subsystem clean up properly.

-- 
Matthew Dharm                              Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

We can customize our colonels.
                                        -- Tux
User Friendly, 12/1/1998

Attachment: msg11212/pgp00000.pgp
Description: PGP signature

Reply via email to