cvs commit: src/sys/cam/scsi scsi_da.c

[mjacob at freebsd.org]

> As long as it's specific to a known external device (USB), and the user knows 
> that running some command (device_eject umass0) will make sure it's safe, I'm 
> ok.

Mmm.

>>> From a silly semantic point of view to get around this, we should still 
>> support and require SYNC_CACHE on close except where devices don't support 
>> it (and any device that hangs on a SYNC_CACHE doesn't support it- period). 
>> On detach, devices that still need to have data commited via an opcode that 
>> looks remarkably like SYNC_CACHE can and should have that happen- with all 
>> the infrastructure changes that go along with allowing devices to be 
>> detached (w/o complaint) with a live command.
>> 
>> Or have I missed something it what you're suggesting?
>
> Actually, that's a different idea I had where you set a timeout() before 
> running SYNC_CACHE, then cancel the command if it hangs.  Not sure how to 
> implement the idea of a cancellable device call but maybe by creating a 
> temporary thread?

Why not just quiet SYNC_CACHE timeouts?

-matt