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 stillsupport 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 _______________________________________________ freebsd-scsi_(_at_)_freebsd_(_dot_)_org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-scsi To unsubscribe, send any mail to "freebsd-scsi-unsubscribe_(_at_)_freebsd_(_dot_)_org"