linux-kernel - Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1170711587.29759.909.camel@pmac.infradead.org>
Date:	Mon, 05 Feb 2007 21:39:47 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.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, 2007-02-05 at 13:28 -0800, Linus Torvalds wrote:
> Right. Because for MOST scsi drivers, it's obvious that they are SCSI to 
> the user.

Really? Including the 'Scanner driver' card which arrived with my
scanner?

Is that like the 'RAID' card which is obviously RAID to the user, and
not at all IDE?

> But if you cannot see that this is something TOTALLY DIFFERENT from USB 
> storage, you're either being obtuse on purpose, or just incapable of 
> understanding humans.
> 
> We should NEVER have had "USB_STORAGE" depending on SCSI. It'sa BUG. It's 
> a _stupid_ bug.
>
> We should have done what is sane:
>  - make CONFIG_SCSI (as a "support the SCSI layer" be invisible to users, 
>    because it's not a user decision.
>  - have a CONFIG_SCSI_DRIVER question for "do you want to be asked about 
>    SCSI drivers" (and which also does "select SCSI" for you)
>  - make USB_STORAGE _also_ do the "select SCSI" thing.

Crap. What we should have done is fix the tools so that when you go to
enable USB_STORAGE, it either prompts you or automatically turns on
SCSI. I saw versions of our tcl xconfig a _decade_ ago which were
capable of this, but we never cared enough to merge it -- although I
_thought_ our new xconfig could do it these days.

> In other words, you seem to be totally unable to grasp my argument. You 
> are arguing on TOTALLY IRRELEVANT TECHNICAL GROUNDS. That's not what the 
> Kconfig language is about. The Kconfig language and rules are about HUMAN 
> interaction.

Well that's a shame, because any sane person would realise that most
humans interact with kernel configuration only through a distribution.

> So next time you say something about Kconfig, ask yourself: "What question 
> would a user want to see".
> 
> Any other question is pretty much totally irrelevant, and your "don't use 
> select" rule comes from your confusion that thinks that it's somehow about 
> machines and technical issues. It's not.

No, really. Eric's Aunt Tillie can go screw herself backwards with a
chainsaw. I care about _my_ use of configuration, and mostly my
requirement is that I want to turn something _off_ either because it
doesn't work, or I want it modular so I can hack on it, or because I'm
trying to cut down kernel size and I don't want it.

The proliferation of 'select' has made that a _complete_ pain in the
wossname, apparently for the benefit of some hypothetical relative of a
gun nut, who doesn't actually care because in general she doesn't
configure her own kernel anyway.

Russell is right -- using 'select' just turns the problem backwards,
pessimising it for the _common_ case.

-- 
dwmw2

-
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/