From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: SCSI Patches - mostly on/off-line stuff
Date: Thu, 18 Jan 2001 22:07:21 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-97985740512366@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-97925037703688@msgid-missing>
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 <miles@megapathdsl.net>
To: David Brownell <david-b@pacbell.net>
Cc: <linux-scsi@vger.kernel.org>; <linux-hotplug-devel@lists.sourceforge.net>
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.
_______________________________________________
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
next prev parent reply other threads:[~2001-01-18 22:07 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-11 21:56 SCSI Patches - mostly on/off-line stuff Douglas Gilbert
2001-01-11 22:43 ` Oliver.Neukum
2001-01-17 20:32 ` David Brownell
2001-01-18 0:08 ` Douglas Gilbert
2001-01-18 9:03 ` Oliver Neukum
2001-01-18 9:25 ` Miles Lane
2001-01-18 15:37 ` Eric Youngdale
2001-01-18 16:20 ` Venkatesh Ramamurthy
2001-01-18 16:49 ` Prasenjit Sarkar
2001-01-18 16:50 ` Venkatesh Ramamurthy
2001-01-18 17:03 ` Venkatesh Ramamurthy
2001-01-18 18:14 ` David Brownell
2001-01-18 19:12 ` Oliver Neukum
2001-01-18 19:20 ` Prasenjit Sarkar
2001-01-18 19:45 ` Miles Lane
2001-01-18 21:08 ` Douglas Gilbert
2001-01-18 21:41 ` Miles Lane
2001-01-18 22:07 ` David Brownell [this message]
2001-01-18 22:15 ` David Brownell
2001-01-18 22:45 ` Oliver Neukum
2001-01-18 23:10 ` Oliver Neukum
2001-01-18 23:25 ` Miles Lane
2001-01-18 23:37 ` Oliver Neukum
2001-01-19 2:08 ` David Brownell
2001-01-19 2:10 ` Bob Frey
2001-01-19 2:16 ` Venkatesh Ramamurthy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-hotplug-97985740512366@msgid-missing \
--to=david-b@pacbell.net \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.