From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Fabio Comolli <fabio.comolli@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
sam@ravnborg.org, linux-scsi <linux-scsi@vger.kernel.org>,
Matthew Wilcox <matthew@wil.cx>
Subject: Re: Possible bug in SCSI Kconfig
Date: Thu, 23 Oct 2008 19:30:33 +0200 [thread overview]
Message-ID: <4900B4B9.4050103@s5r6.in-berlin.de> (raw)
In-Reply-To: <1224704659.6851.28.camel@localhost.localdomain>
James Bottomley wrote:
> On Wed, 2008-10-22 at 21:25 +0200, Fabio Comolli wrote:
>> But in my case I have SCSI enabled only because it's SELECTed by ATA
>> (it's just a laptop) and I don't have any hba's and never will. So no
>> async scan.
>
> Presumably you have a laptop hard disk. That's currently SCSI if you
> use ATA ... although when ATA moves out of SCSI it will no longer be, so
> you could regard this as a temporary condition.
What USB storage? And more.
>> Maybe this module should be enabled if async scan is.
>
> But that's the point: async scan is always "enabled" it just might not
> be the default, that's what the CONFIG_SCSI_SCAN_ASYNC controls: the
> default value (but you can always turn it on with the kernel boot or
> SCSI module option). Async scan is also functional for /drivers/ata and
> other hot plug type busses, so it still makes sense for them as well.
...
> Well, we do use CONFIG_MODULES to try to discern whether the user wants
> modules or not. However, if you enable modules, we'd need some
> telepathic configurator to tell us if you plan to use SCSI HBA modules
> or not, so the safest course is always to enable it. The real point is
> that you have to be a real power user to answer N correctly to this, so
> it's better not to confuse the remaining 97% with the option because
> they could easily get wrong ...
Is it remotely possible that SCSI_WAIT_SCAN could depend on or be
selected by transports which actually cooperate with scsi_wait_scan?
Also remember:
- Writing "Depending your initrd, this module may be necessary for
the system to boot up." and "If unsure, say M." in the Kconfig help
text is always an option.
- I haven't built an initrd since ages, but I presume that initrd
build scripts will complain if an expected module is missing.
- scsi_wait_scan is a special method to wait for devices during boot
which only works with some hardware types. More general methods are
available and have been in use far longer than scsi_wait_scan
exists. Nobody fundamentally needs scsi_wait_scan, it is only a
convenient tool for some users who choose to use it.
Special features are traditionally per default off in Kconfig and
are supposed to be actively enabled.
The sentence "this module may be necessary for the system to boot up" is
actually applicable to a myriad of options which have a prompt and
default to off. The only difference is that most of these options are
easier to explain. And that's what it boils down to: You omitted the
prompt because you felt it was too hard to explain.
> the 3% who're sure they don't want it can simply delete it.
Yeah, or remove the line from .config, or... change scsi/Kconfig to get
a prompt.
--
Stefan Richter
-=====-==--- =-=- =-===
http://arcgraph.de/sr/
next prev parent reply other threads:[~2008-10-23 17:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-22 16:29 Fabio Comolli
2008-10-22 18:35 ` Stefan Richter
2008-10-22 19:29 ` Fabio Comolli
2008-10-22 19:05 ` James Bottomley
2008-10-22 19:25 ` Fabio Comolli
2008-10-22 19:26 ` Matthew Wilcox
2008-10-22 19:31 ` Fabio Comolli
2008-10-22 19:34 ` Matthew Wilcox
2008-10-22 19:45 ` Fabio Comolli
2008-10-22 19:44 ` James Bottomley
2008-10-22 19:48 ` Fabio Comolli
2008-10-23 17:30 ` Stefan Richter [this message]
2008-10-23 17:39 ` Matthew Wilcox
2008-10-23 18:59 ` Stefan Richter
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=4900B4B9.4050103@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=fabio.comolli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=sam@ravnborg.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
all inboxes | Powered by JetHome®