From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miles Lane Date: Thu, 18 Jan 2001 23:25:41 +0000 Subject: Re: SCSI Patches - mostly on/off-line stuff Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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 _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel