>
> The key is that the removal request should come from the top, not the
> bottom. If someone is stupid enough to surprise remove a device (ie:
> unplug their USB SCSI device while the device is in use by the OS), they
> get what they deserve (I/O errors, dirty OS data, queued up requests
> which
ogram that is started that
> allows you to notify the os of the removal so that it may properly
> remove the device from the OS instead of it being yanked.
>
> Thanks
> -steve
>
> Matthew Jacob wrote:
>
> >>The key is that the removal request should come fr
> I want:
> LLDD to SCSI: device is gone
> SCSI to LLDD: Ok. I'll handle from here on.
> LLDD: OK. I am gone. And won't have any contact until the next device is
> plugged in.
>
> The process can be somewhat more complicated, under some conditions:
> - it never fails
> - it is done within a finite,
> >>...
> >
> >
> > Could this time limit be fixed (or parameterized) known to all LLDDs?
> > This would allow one to try and avoid flooding SCSI with detach/reattach
> > events for the 'same' device.
>
> And what exactly is the "same" device? And who's keeping history
> about devices that have p
>
> It's like when I pull the power plug because my system is totally hosed and
> I want to start over. I know I can cause damage by doing that, but I would
> be upset if the new system booted back to the broken state it was in when I
> unplugged it.
I had this conversation with doug offlist- thi
