From: Linus Torvalds <torvalds@linux-foundation.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Adrian Bunk <bunk@kernel.org>, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Greg KH <greg@kroah.com>
Subject: Re: [GIT PATCH] SCSI updates for 2.6.25
Date: Sat, 19 Apr 2008 13:14:23 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0804191305360.2779@woody.linux-foundation.org> (raw)
In-Reply-To: <1208626496.3280.40.camel@localhost.localdomain>
On Sat, 19 Apr 2008, James Bottomley wrote:
>
> Well, we already had this argument on linux-scsi when the interface was
> first proposed: Apart from select being very nasty and should only be
> sparingly used
I'm still not understanding people who say that.
Yes, select has problems, in that it doesn't guarantee dependencies.
But that said, select is a whole lot better than having simply *different*
behaviour (or build errors) depending on totally unrelated config options.
So people: stop this total *idiocy* with "select is bad". It's not. The
lack of select is *much* worse.
If you want LIBSAS to have two different modes, how about just making that
explicit in the configuration, ie using something like
config LIBSAS_SET_ADDR
bool "Provide user-settable SAS address"
depends on SCSI_SAS_LIBSAS
help
This allows a runtime "firmware" loader that loads the
SAS address
config LIBSAS_SET_ADDR_FWLOAD
tristate
depends on SCSI_SAS_LIBSAS && LIBSAS_SET_ADDR
default y
select FW_LOADER
and now you have the explicit option to turn it on or off - and FW_LOADER
is loaded appropriately.
> Even if I changed it to select, a user could still defeat it by making
> CONFIG_SCSI_AIC94XX=y (because now the initialisation is before early
> boot userland, so the request always fails).
Not true. That's why we have initrd and ramdisks etc.
Not that any normal people will ever care about LIBSAS, but anyway.. The
ones that do care about these kinds of things are probably happy to have
special initrd images.
Linus
next prev parent reply other threads:[~2008-04-19 20:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-18 17:41 James Bottomley
2008-04-19 15:19 ` Ingo Molnar
2008-04-19 15:54 ` James Bottomley
2008-04-19 16:42 ` Ingo Molnar
2008-04-19 17:05 ` Adrian Bunk
2008-04-19 17:34 ` James Bottomley
2008-04-19 20:14 ` Linus Torvalds [this message]
2008-04-19 20:45 ` Matthew Wilcox
2008-04-20 14:09 ` Stefan Richter
2008-04-20 19:56 ` Matthew Wilcox
2008-04-20 20:14 ` Stefan Richter
2008-04-28 21:00 ` Sam Ravnborg
2008-04-28 21:01 ` Matthew Wilcox
2008-04-19 22:27 ` James Bottomley
2008-04-19 23:14 ` Matthew Wilcox
2008-04-21 12:51 ` Ingo Molnar
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=alpine.LFD.1.10.0804191305360.2779@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=bunk@kernel.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mingo@elte.hu \
/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®