[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0702061516110.8424@woody.linux-foundation.org>
Date: Tue, 6 Feb 2007 15:28:13 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Woodhouse <dwmw2@...radead.org>
cc: Randy Dunlap <randy.dunlap@...cle.com>,
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 Tue, 6 Feb 2007, David Woodhouse wrote:
>
> The other possibility which comes to mind, and which I _have_ seen
> implemented, is not to hide the disabled option but to _show_ it, and
> represent its dependencies right there next to it somehow.
That would probably work, especially if you had some way to "warp" to the
other options (so that if you see "depends on SCSI" you could say "ok, go
to SCSI then".
However, I have this suspicion that you'd just drown in options that you
really don't want to see.
> Well one option, as you suggest, is just that if you go into the
> graphical tool and enable USB_STORAGE, you get SCSI turned on
> automatically.
Yes. That basically is what "select" means, though. The difference is,
indeed, largely about visibility.
If everything was always visible, there really wouldn't be much of a
difference between "depends on" and "select". In both cases, when you
click on something that depends on or selects something else, the config
tool would obviously select it.
So yes, you can make "depends on" and "select" mean _exactly_ the same
thing. But basically only by always showing everything. Which I don't
think you want. If I say I don't want IPv6, I really am not interested in
seeing some IPv6-only questions. But on the other hand, maybe there is
something that _needs_ IPv6 to work, and then maybe I'd like it enabled..
(Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might
still want to be able to see the question about NFSv8.1, which only works
on top of IPV6. I might not even *know* I want IPV6, but I know my company
uses NFSv8.1, so I say "yes").
And I realize that was a contrieved example, but there are *real* examples
of this in the kernel today. I may well know that I want 802.11 WEP
encryption, for example, but I sure as hell had *no* clue that it requires
ARC4.
See the problem? I may be a well-educated user who doesn't even *know*
that I actually want an encrytion algorithm that I've never heard of. For
all I knew, the 802.11 WEP stuff was done inside the wireless cards by
hardware..
Does that mean that if I don't have CRYPTO_ARC4 enabled (which in turn
would need CRYPTO_ALGAPI enabled too) I'd not even get the choice of WEP?
Obviously that is broken.
And yes, if you *always* get the choice of *everyting*, then it all boils
down to the same thing. I just don't think you do..
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