From: Matthew Wilcox <matthew@wil.cx>
To: Douglas Gilbert <dougg@torque.net>
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] async scsi scanning, version 12
Date: Thu, 28 Sep 2006 14:36:56 -0600 [thread overview]
Message-ID: <20060928203656.GG5017@parisc-linux.org> (raw)
In-Reply-To: <451C2D49.7040403@torque.net>
On Thu, Sep 28, 2006 at 04:15:05PM -0400, Douglas Gilbert wrote:
> > + scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they are
> > + discovered. async scans them in kernel threads,
> > + allowing boot to proceed. none ignores them, expecting
> > + user space to do the scan.
>
> Matthew,
> I like the "none" which is no doubt a place holder at
> the moment.
I wouldn't say it was extensively tested, but no, there's checks for the
value "none" and it does indeed fail to discover any devices ;-)
> For the user space to do discovery, it either needs an out
> of band mechanism (e.g. IP) or the ability to talk to a
> host in the absence of any "devices" (targets or logical units).
> That requires a device node (e.g. /dev/mptctl) or something
> equivalent in sysfs (yuk).
I must confess to having not thought about how userspace probes a
scsi host to find out what devices are behind it. This was a feature
that James asked for and it was easy to add.
> Your "none" explanation could be slightly extended to say
> that the LLD (and/or its firmware) might do the discovery.
Note that by specifying "none", not even the FC/SAS/etc drivers can
register targets as they find them -- it really is up to userspace to
echo scsi-add-single-device H C T L >/proc/scsi/scsi
I'm a little uncomfortable with that, and I'd be open to adding another
word that means "no scanning, but if the driver's been told about the
device by a switch, add it automatically, don't wait for userspace".
I do think that none needs to mean none though.
> As an
> example the SAS-2 draft now has self-configuring expanders
> (the terms "edge" and "fanout" have been dropped) which
> effectively discover the topology and track changes, configuring
> themselves and dumber expanders as required. Then host discovery
> becomes importing the topology from an external device. However
> not all devices may be visible to self-configuring expanders
> (e.g. a SATA disk could be directly attached to a SAS HBA). So
> some extra work may be required.
That would be up to userspace in the "none" view of the world. I could
see people wanting to ignore the self-configuring expander and impose
a new (incorrect) topology on the system.
BTW, there'll be a lucky version 13 in a few minutes ...
shost_for_each_device_safe isn't.
next prev parent reply other threads:[~2006-09-28 20:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-28 18:24 [PATCH] async scsi scanning, version 12 Matthew Wilcox
2006-09-28 20:15 ` Douglas Gilbert
2006-09-28 20:36 ` Matthew Wilcox [this message]
2006-09-28 20:32 ` Andrew Morton
2006-09-28 20:40 ` Matthew Wilcox
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=20060928203656.GG5017@parisc-linux.org \
--to=matthew@wil.cx \
--cc=dougg@torque.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@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.