linux-kernel - Re: Crypto Update for 3.2

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]

Date:	Mon, 31 Oct 2011 10:16:55 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Randy Dunlap <rdunlap@...otime.net>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: Crypto Update for 3.2

On Mon, Oct 31, 2011 at 9:42 AM, Randy Dunlap <rdunlap@...otime.net> wrote:
>
> Actually adds "select NET", a reverse dependency.  :(
>
> Linus was quite vocal about not allowing MD to select BLOCK.
> See https://lkml.org/lkml/2011/8/10/527
> and https://lkml.org/lkml/2011/8/10/533
>
> To me this is very similar.

I do agree.

"select" makes sense when it's a way for a user to not have to care
about some small helper thing that is really not obvious for a casual
user.

But darn it, if somebody has said "no networking", then some random
small feature shouldn't suddenly select it.

IOW, it's about "relative importance". We should use "select" when
some feature that should be user-visible selects some details. And we
should use "depends on" when there's a major subsystem that some small
detail depends on.

So classic and obvious uses where "select" is appropriate is when a
driver needs some helper library to work (eg "select FW_LOADER" or
"select CRC32").

And a classic and obvious case where "depends on" is the appropriate
choice is when it depends on a major subsystem ("depends on PCI" or
"depends on USB" or "depends on X86").

And I think "NET" definitely falls into that second category - exactly
the same way "BLOCK" fell into it. You don't "select" major subsystems
- if somebody turned off the subsystem, we turn off the stuff that
depends on it.

(Of course, in reality, pretty much nobody turns off NET, I suspect.
But if some embedded place really doesn't want it, then damn it, we
shouldn't ask about the odd crypto user interfaces, because they
really aren't major enough, and the embedded platform is clearly
trying very hard to run small).

                        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/