[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0702051409110.8424@woody.linux-foundation.org>
Date: Mon, 5 Feb 2007 14:21:41 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Woodhouse <dwmw2@...radead.org>
cc: Ingo Molnar <mingo@...e.hu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, David Woodhouse wrote:
>
> Ten years ago, people used 'depends on' to fix the tools, so that then
> you want to enable something like USB_STORAGE, it can automatically turn
> SCSI on for you.
>
> Isn't that what you wanted?
Try it. It's not what it does.
If you have a
depends on SCSI
and you did not say you wanted SCSI, you'll never even *see* the question.
It will *not* turn on SCSI automatically for you. Quite the reverse. It
will not even show you the option.
In contrast, it you do a
select SCSI
you'll see the question, and it will do exactly what you claim "depends
on" does. Which yes, is what we want.
So what's your problem? You argue as if you didn't understand the
difference between "depends on" and "select".
As an example of this, look at SATA. It does "select SCSI" if you select
CONFIG_ATA, _exactly_ because it actually wants to turn on the SCSI layer
*regardless* of what the user said. Because if the user said "n" to SCSI,
the user simply didn't know that the SATA code uses the SCSI code.
Which is an example of what I've been saying all along: "select" makes
sense. USB_STORAGE should have done the same.
Claiming that "select" is evil is just totally strange.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists