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: <45C91DB0.8060308@oracle.com>
Date:	Tue, 06 Feb 2007 16:30:40 -0800
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	David Woodhouse <dwmw2@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

Linus Torvalds wrote:
> 
> 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.

That seems odd to me.  I usually use edit + oldconfig to disable a
symbol.  Maybe to enable a symbol occasionally.  But the symbols
that I want to enable usually aren't listed in .config at all,
so I end up using another config tool to enable them.
E.g., a sound driver when SOUND is completely disabled.

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