Am Donnerstag, 23. Januar 2003 21:41 schrieb Steven Dake: > Oliver and others, > > In regards to hotswap, any real operating system should be _told_ that a > block device is going to be removed from the top. There are several > reasons.
Users don't do what they should. It is as simple as that. The hotplugging busses are supposed to handle that. > 1) File mounts should be removed from the filesystem layer > 2) files accessing block devices directly should be terminated > 3) raid members using that block device should be hot removed > 4) I'm sure you can think of others :) > > 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: No! You have to be able to handle a sudden failure. If you don't do this you are already buggy. Hardware doesn't send advance notification before failing. Data loss will occur. It's unavoidable. Anything else must not happen. And a failure of hardware can only be recognised at the layer closest to the hardware in the generic case. > The device driver should not be responsible for managing hotswap in any > regard. Its only purpose should be to tell the block device removal Yes. > layer that a surprise extraction was initiated such that the block > device removal code can ask the mid layer drivers to shut down error > correction routines to the device and dump its pending I/O queue and > clean up after the device. The main advantage of this technique is Yes. But not ask. Demand. There's no asking here. Do or die. > If you think about what your suggesting, your suggesting that the LLDD > tells the scsi layer that the device is gone, that then times out errors > and leaves the filesystem and sys_open/close file tables, and RAID > layers in a state of disarray. We don't want the LLDD knowing about the > RAID system and whether it should tell the RAID layer to hot remove, do we? 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, bounded, reasonable time Regards Oliver ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel