linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de>
To: linux-hotplug@vger.kernel.org
Subject: Re: SCSI Patches - mostly on/off-line stuff
Date: Thu, 18 Jan 2001 23:37:54 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-97986101223513@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-97925037703688@msgid-missing>


> > 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?

If I understand this correctly, "pending" is a state which indicates
that a physical device has been unplugged, but the connection between
that device's node (and fds) and the driver still exists. At some point 
(no more open fds) the driver would be free to break the node <-> driver
relation. If indeed the device is replugged in the pending period the driver
could go back from "pending" to "active". (If there's no state to be lost)

For the user any action on an fd should either yield an error or block.
Probably open should fail.

However I'd like to see the decision to go from pending to gone in the common 
core where possible, eg. in the scsi upper layer. The same should be true for 
the decision when to return an error to user space.

	HTH
		Oliver

_______________________________________________
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

  parent reply	other threads:[~2001-01-18 23:37 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
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 [this message]
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-97986101223513@msgid-missing \
    --to=oliver.neukum@lrz.uni-muenchen.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).