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

Reply via email to