linux-kernel - Re: [GIT] kbuild core updates for 2.6.39-rc1

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: <AANLkTin5vYaU83K0YOdD1OgCS24LA8XBSvNfmGFnjhGF@mail.gmail.com>
Date:	Sun, 20 Mar 2011 17:53:24 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Michal Marek <mmarek@...e.cz>
Cc:	bp@...en8.de, dot@...at.at, mikew@...gle.com,
	randy.dunlap@...cle.com, u.kleine-koenig@...gutronix.de,
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT] kbuild core updates for 2.6.39-rc1

On Sat, Mar 19, 2011 at 1:58 AM, Michal Marek <mmarek@...e.cz> wrote:
>
> * Section mismatch analysis enabled by default
>  - there are only a few warnings for defconfig builds,
>    all{yes,mod}config still has a lot of them. Depending on the general
>    perception of this change, we might disable it later in the rc phase
>    again.

No.

We don't enable stuff like this by default. Not when it actually
changes some really fundamental compiler flags, and thus the whole "we
can disable it late in -rc again" is a totally broken option, since if
we have any compiler issues, we'd want to know it early.

And we _know_ we are going to disable it, since it enables the "don't
inline" flag to gcc for called-once functions. So there's no question
at all what the default should be in any release kernel.

Anyway - in general, enabling options like this had better have some
_seriously_ major reasons. IOW, major known issues that just have to
be sorted out and cannot be sorted out any other way. That doesn't
seem to be the case here.

WE DO NOT EVER ENABLE NEW THINGS BY DEFAULT. I know, I know - every
developer always thinks that _his_ code is special and magically so
important that it should be enabled by default, but no, that is simply
not the case. The only reason to enable something by default is that
it used to never be a config option in the first place, so if somebody
builds a new kernel, and he used to just silently get the feature,
then the new config option is still on by default.

Not pulling. This is a pet peeve of mine. We don't use "set to 'y' on
default" as a way to trick people into enabling code. No, no, no.

                             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/