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: <Pine.LNX.4.64.0702061615480.8424@woody.linux-foundation.org>
Date:	Tue, 6 Feb 2007 16:21:30 -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 Wed, 7 Feb 2007, David Woodhouse wrote:
> 
> It isn't that far off, and we could improve it if we wanted to. In
> _general_ it's quite good already.

I agree that it's close to hierarchical. But it's literally the exceptions 
that get you.

Let me mention (again) USB_STORAGE and ATA.

They are not "under" SCSI. Making them do that would be insane.

But yes, you can do hierarchies by adding "pseudo-variables": as 
mentioned several times, we could actually split CONFIG_SCSI into two 
separate ones: CONFIG_SCSI that selects the core infrastructure, and 
CONFIG_SCSI_DRIVER that actually controls the "hierarchical visibility". 

Then CONFIG_SCSI_DRIVER (and USB_STORAGE, and SATA) would just do a simple 
'select SCSI'. It would _not_ be hierarchical, and it would very much use 
that same old "select", but it would possibly be a cleanup at least in the 
sense that now CONFIG_SCSI wouldn't be used two different ways (one to 
hide most SCSI drivers, and one to enable the core SCSI infrastructure 
code).

> It would work quite nicely in the graphical tools, although you've
> thrown me a little by wanting it in the hacker's tool 'oldconfig' too.
> You obviously care more about turning stuff _on_ with 'make oldconfig'
> while other people who've spoken up seem to care more, as I do, about
> turning stuff _off_ that way. If I want my hand held, I'm happy enough
> to use the graphical tools.

I tend to just edit the .config file, and run "make oldconfig". And I know 
I'm not the only one, because I've talked to others who do the same.

And yes, then it's almost always correct to "turn things on as needed to 
make everything work out right", while turning things off would be 
actively wrong.

		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/