linux-kernel - Re: [PATCH 19/62] Driver-Core: devtmpfs - remove EXPERIMENTAL and enable it by default

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:	Wed, 3 Mar 2010 08:46:54 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
cc:	Greg Kroah-Hartman <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	Kay Sievers <kay.sievers@...y.org>
Subject: Re: [PATCH 19/62] Driver-Core: devtmpfs - remove EXPERIMENTAL and
 enable it by default

On Tue, 2 Mar 2010, Eric W. Biederman wrote:

> Greg Kroah-Hartman <gregkh@...e.de> writes:
>> 
> > From: Kay Sievers <kay.sievers@...y.org>
> >
> > All major distros enable devtmpfs on recent systems, so remove
> > the EXPERIMENTAL flag, and enable it by default to reflect how it
> > is used today.
> 
> Default y?
> 
> Default y is the wrong thing for DEVTMPFS_MOUNT.  It changes the
> userspace semantics so I can't see how this is safe in the general
> case.
> 
> I also looked and the most recent bleeding edge distro I have fedora
> core 12 doesn't even compile in devtmpfs so this extraordinary claim
> that all major distros are using devtmpfs is far from true today.  It
> is certainly rare enough that changing there is not yet justification
> for changing the default.

Yeah, this justification is pure and utter sh*t.

We don't just randomly move it from EXPERIMENTAL to make it 'default y'.

In fact, as mentioned yesterday in an unrelated thread, we NEVER make 
something 'default y' unless it is required to maintain _old_ semantics 
(ie some config option that is required for previous behavior to be true), 
or unless it cures cancer.

Guys, I'll say it one more time: developers always feel that _their_ 
particular code is so important that it needs to be 'default y', because 
obviously their code must be used by everybody.

But that is pure and utter CRAP.

Something like the core input layer might be 'default y' because quite 
frankly, for 99% of users, if you don't enable it, the machine is useless. 
And the original keyboard driver used to be compiled in without question. 
And people who really don't want the input layer really _are_ special.

But some random new feature that nobody actually uses, has no legacy 
reasons? Nope. It's simply not 'default y' material.

So I'm not going to pull this crap. People need to learn that 'default y' 
is just WRONG.

Greg, please shut down people like Kay that want to enable something by 
default. We want a _minimal_  working config, not a maximal. If somebody 
has a distro that needs this, they can enable it _then_. Not "let's try to 
make people enable it whether they need it or not, because they _might_".

Because "might need it" is simply not good enough. A "must have" is the 
only reason to do 'default y'.

		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/