[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20250610173228.49109-1-sj@kernel.org>
Date: Tue, 10 Jun 2025 10:32:28 -0700
From: SeongJae Park <sj@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: SeongJae Park <sj@...nel.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Honggyu Kim <honggyu.kim@...com>,
linux-mm@...ck.org,
mm-commits@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Additional MM updates for 6.16-rc1
On Tue, 10 Jun 2025 10:27:46 -0700 Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Tue, 10 Jun 2025 at 09:41, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> >
> > Just revert the commit?
>
> Yes. We don't do "default y" for random features.
>
> EVERY SINGLE DEVELOPER thinks that *their* feature is so important
> that everybody else should enable it.
>
> And if that feature wasn't enabled before, they are completely wrong
> 99% of the time.
>
> There is a very real reason why 'default' defaults to 'n'.
>
> So we do *not* use "default y" for features that aren't universal.
>
> The only time we should use 'default y' is if some old feature that
> used to be unconditional gets split up into a new Kconfig variable and
> not using 'default y' means that people *lose* functionality.
>
> Or if the feature is some critical security thing, or is some hardware
> thing that has become so universal that you find it on basically every
> single machine.
>
> Or if that feature cures cancer or brings world peace.
>
> Then you can enable it by default.
>
> I have reverted that 'default y' thing, because I see no reason to
> believe that DAEMON cures cancer.
Makes sense, and thank you for explaining these all. I will keep thse in my
mind to avoid making same mistakes in future.
Thanks,
SJ
[...]
Powered by blists - more mailing lists