linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 18:14:11 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-97984242226604@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-97925037703688@msgid-missing>

Douglas, thanks for that overview of the structure of the SCSI
subsystem -- I needed one, that was better than I'd suspected
I'd find!

It seemed to me that something was missing in that stack though;
the layers above (4), specifically filesystems, that would also need
to know about new devices that were added.  When everything is
working smoothly, users need to see filesystems get mounted as
a direct consequence of hotplugging such storage units.

One way to look at that issue is to ask what user mode notifications
will be used to address that part of the hotplug problem.  Devfsd
is what some folk like, but it's not universally accepted.  GUI
driven solutions don't seem right in all cases either. 


Eric:

>     As far as the mid-layer is concerned, hotplugging more or less consists
> of two independent tasks.  Addition of new devices, and removal of devices.

Exactly.  That is, if you will, one of the first architectural requirements.
Once that's addressed, everything else starts to fall into place.

As I understand things, USB-to-SCSI adapters (like most usb-storage devices)
will also have "bus" add/remove events to deal with.  Likewise with cases
like hotplugging a SCSI controller on a Cardbus laptop, or on a CompactPCI
(or HotplugPCI) enterprise level server.  Presumably those cases aren't
as troublesome?

You commented that "hot unplugging a device is a bit trickier" ... yes!

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.)


>     Anyways, my initial question reallly has to do with exactly how one is
> notified that a new device has appeared and whether a bus scan needs to be
> initiated or not.   That will control the degree to which we have to screw
> with things in the mid-layer to support this.

Reasoning by analogy for a moment ... USB and Cardbus both have kernel
threads (khubd, and the cardbus watcher) tasked with detecting such stuff.
Also, it's plausible to me to require "add new device" processing to have
a thread context to work with, like "remove device"; again, USB and Cardbus
both have that requirement.  So it seems to me that having some thread(s)
involved here will be the typical case.  Presumably that means that the
mid-layer code would need to accomodate that model. 

- Dave







_______________________________________________
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 18:14 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 [this message]
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
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-97984242226604@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 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).