From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Thu, 18 Jan 2001 22:07:21 +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 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? - Dave ----- Original Message ----- From: Miles Lane To: David Brownell Cc: ; Sent: Thursday, January 18, 2001 11:45 AM Subject: Re: SCSI Patches - mostly on/off-line stuff > David Brownell wrote: > > > > > The notion of a "pending remove" state has crossed my mind too. "New style" > > networking drivers seem to have something like this, and USB has analagous > > issues. Re tying it into the module subsystem, I'll have to try that idea > > on for size; the module system doesn't really know about "devices" as such, > > and maybe it should. (Something needs to.) > > This "pending remove" would be a flag that could be unset > at any point before the device removal occurs, right? > > m. _______________________________________________ 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