David Brownell wrote:
>
> Well, now that I think of it ... this may be a good way to capture
> the two different kinds of "remove". Think of "remove" as breaking
> a binding between device and driver, and these scenarios:
>
> - One "remove" is done by removing the hardware. That
> can't really be reversed ... gotta clean up any messy
> device and "higher level" state, errors all around.
>
> - Another is done by sysadmin request. Hardware still
> there, driver still there ... but they're not bound.
> (Maybe it's install-new-driver time, say, or to make
> sure hardware removal won't cause trouble.)
>
> In that latter case there's a lot of flexibility. Why are you
> thinking a "remove" might want to get undone?
Would you clarify how you envision a user working with a
pending remove? Is it an implementation where a long
period of time might pass before the the device is actually
removed?
Could something like this happen?
- I start compiling XFree86 on a removable device and tell
the system to unmount the media and remove the device
when the compile is complete, a "pending remove" is set.
- During the compile, I realize that I want to make some
additional source modifications, so I want to cancel the
device removal and continue accessing the device.
I may be misunderstanding the sequence of events and how
that might impact a user.
Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
