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: <1170710272.29759.894.camel@pmac.infradead.org>
Date:	Mon, 05 Feb 2007 21:17:52 +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:58 -0800, Linus Torvalds wrote:
> More importantly, some things that *are* visible probably shouldn't be, or 
> should perhaps only be in expert mode (aka "EMBEDDED").

I've heard some fairly stupid abuse of the term 'embedded' in my time,
but rarely have I heard people daft enough to abuse it to mean 'expert'.
But yes, that's what we use CONFIG_EMBEDDED for.

> A prime example of this is all the firewall settings. I'd personally 
> prefer to just select a "default firewall setup" which would be enough 
> for all the normal crud, instead of seeing 50 different choices. 

No, that's a really poor example. That's not what 'select' is for. We
can handle that kind of thing perfectly well without select -- just with
sensible _defaults_, much as we do for block device partitions and a few
other  things.

> Me, I'd like to say I want "default firewall built in", and not have to 
> see *any* of the crap. And that's exactly why "select" is a good thing.
> 
> Not using select, and have people having to say "y" to the basic feature 
> and then y/m/n to each sub-feature is really damn annoying.

No, you're thinking of something else. The use of 'select' just turns
the problem backwards -- if _every_ SCSI hostadapter were to 'select
SCSI' instead of depending on it, then I'd have to say 'n' to every damn
one of them instead of being able to just say 'n' to SCSI as I can at
the moment.

Well, I say 'just turns it backwards', but in fact it also makes it much
worse, because it's now much _harder_ to turn SCSI off, because there
might be random stuff else elsewhere in the tree which selects it rather
than having all the dependencies right on the option I'm interested in,
where I can see them and turn them on/off as required.

The dependency thing for Aunt Tillie is easily fixed in the tools, and
the firewall example you're thinking of is _far_ from being an example
of why 'select' is useful.

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