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 13:48:08 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Greg KH <gregkh@...e.de>
cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	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 Wed, 3 Mar 2010, Greg KH wrote:
> 
> Ok, I'll change this.  Do you want me to redo the whole series, or just
> add another patch to revert the 'default y' option here?

I'm ok with just changing the default. I wanted to make a stink over it 
just to make people aware that we already have kernels too big by default, 
and we shouldn't change the default semantics of making a config without 
some major reasons.

Btw, I do think that when you do pull requests during the merge window, 
you should seriously think about basing them on top of some known-stable 
kernel (ie the previous release) rather than some random 
kernel-of-the-day like you seem to.

It's much easier to bisect problems if you'er not fighting multiple 
overlapping bugs, for example - and since you move from quilt to git 
apparently just based on whatever was the most recent git tree when you do 
that move, it really means that in case the kernel you picked was 
unstable, it's going to be a _bitch_ to bisect any problems introduced in 
your series.

Why? Say that the base you picked happened to simply not boot at all (or 
had something like the PCI problem that I encountered that made X not run 
on my machine) for somebody. Now _all_ those commits you did in that 
series are going to be essentially untestable on such a machine - and 
think about what happens if the problem happens mainly on the same 
machines that had the other bug too?

Anyway, I don't know whether you picked a good spot to do your series or 
not, but it _looked_ like a pretty random spot. It might be perfectly 
good. But just in general, since you always generate your trees from a 
quilt series anyway, I suspect we migth be better off (at least for the 
initial merge window series) to base them on the closest thing we have to 
a "known good" base, namely the previous release. Rather than some "maybe 
fine" point in the middle of the merge window.

			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/