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 <[EMAIL PROTECTED]>
To: David Brownell <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, January 18, 2001 11:45 AM
Subject: Re: SCSI Patches - mostly on/off-line stuff
> David Brownell wrote:
>
> <snip>
>
> > 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
