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.0702051424020.8424@woody.linux-foundation.org>
Date:	Mon, 5 Feb 2007 14:35:00 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alan <alan@...rguk.ukuu.org.uk>
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

On Mon, 5 Feb 2007, Alan wrote:
> 
> It works both ways. If I don't need to know that I must select SCSI then
> it turns on easily. If I want to turn SCSI off then it causes mayhem. Two
> sides of the same coin.

They are not really symmetric, though.

There's two big issues:

 - tuning things "on" is more likely to cause a working kernel.

   This is pretty fundamental. It's almost always simply more correct to 
   add features than remove them. At worst, it won't be used.

   This argues that you should have to "work less" to turn something on, 
   and in particular, you should need to _know_ less. To turn something 
   off, you not only need to know how to turn it off, you fundamentally 
   need to know something much bigger: you need to know that you 
   really don't need it in the first place.

   The interaction of CONFIG_ATA/CONFIG_SCSI is an example of the latter. 
   You really *do* need to know more to turn off SCSI - because you need 
   to know that the ATA layer depends on it.

   So in the absense of knowledge, turning things on is better.

 - A developer who really wants to turn things off, and knows enough that 
   that is actually safe, can really just do a "grep" for it. If you're 
   _extremely_ knowledgeable, you can do something like

	git grep 'select.*\<SCSI\>' -- '*onfig*'

   and that easily finds you the (currently single) place that turns on 
   SCSI (and yes, you can try it with I2C too, and try to recursively 
   figure out what it is that turns on I2C even though you *tried* to turn 
   it off. I2C - the option that just wouldn't die! ;)

So I agree that they are two facets of the same coin, but I claim that 
there's a huge reason why they are not mirror-images - there are often 
reasons to prefer one over the other.

That said: I really don't think "depends on" should just always be 
"select" either. There's a balance:

 - you use "depends on" when you can ask a simple question like "what kind 
   of machine do you have" or "do you want to support USB" or "do you have 
   SCSI devices". 

   But even then, you might end up having some devices that are 
   *technically* USB, but people don't think of them that way (for 
   example, some laptop add-ons are literally USB devices that are "built 
   into" the laptop - you might well decide to show those choices even if 
   somebody said "no USB", and if he then says "yeah, I have one of those 
   things", you just know he wasn't clueful enough, and you enable USB 
   behind his back _anyway_. Exact same thing as with SATA support)

 - you use "select" when the question more naturally went the other way 
   (because the infrastructure isn't obvious)

So they are two similar things, and which one to choose mainly depends on 
how you want to phrase the question - not on technical issues per se.

So neither is "wrong". They both have their downsides. 

		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/