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: <1170694340.29759.883.camel@pmac.infradead.org>
Date:	Mon, 05 Feb 2007 16:52:20 +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 08:32 -0800, Linus Torvalds wrote:
> 
> On Mon, 5 Feb 2007, David Woodhouse wrote:
> > 
> > Secondly, please don't _ever_ use 'select'.
> 
> No, David.
> 
> I don't know why you keep repeating this mantra, when it's WRONG.

It may not shock you to find that I repeat it because I disagree.

> Using "select" is a lot more sane and intelligent than assuming that users 
> know what dependencies they want.
>
> The Kconfig files should ask about *end-user* visible features. They 
> should say "do you want to support X".

For the benefit of some, that's useful. Others still want to be able to
turn off entire subsystems when they don't compile or when they want to
quickly build a minimal kernel. It's become very hard to do that though.

> If "X" then needs Y, Z and something else to actually compile, then that 
> Kconfig file should DAMN WELL use "select". Stop claiming anything else!

I agree that the tools should let them do that easily. It doesn't
necessarily follow that we should use 'select' for that purpose.

> The user shouldn't know that they should say that they need some library Y 
> in order to even see the question for "X". It's not a sane thing to ask 
> them to know and care about. They care about the devices or capabilities 
> they want to support, not about the fact that a USB storage device needs 
> the SCSI core layer, for example.

This I agree with. And it's something which the _tools_ have been
capable of for a long time. You don't need 'select'. 

The problem is that the widespread and inconsistent use of 'select' for
Aunt Tillie's benefit causes problems for a _different_ set of people.
To use Ingo's example -- if I want to turn off CONFIG_I2C because it
doesn't build or I want it modular to hack on it, I want to be able to
just _do_ that.

I don't want to find that it's forced to 'Y' because I also happen to be
building support for some esoteric peripheral that I've never heard of.
I want that that peripheral to be turned _off_ when I turn I2C off. I
don't want to have to spend hours grepping _all_ over the tree to find
out what's forcing I2C on again. When it was just dependencies, it was
easy enough to find -- it was right there in the Kconfig file in one
place. Now it's a lot harder.

And I'm sure you aren't seriously suggesting that we should take it all
the way and that, for example, all SCSI host drivers should 'select
SCSI' rather than merely depending on SCSI? If I configure a kernel I
don't _want_ to be asked individually about every leaf option -- I want
to be able to turn stuff off in an orderly fashion; in a tree as Ingo
suggests.

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