linux-kernel - Re: [GIT PULL] Squashfs pull request for 2.6.29

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: <20090122222648.GC31487@elte.hu>
Date:	Thu, 22 Jan 2009 23:26:48 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Greg KH <gregkh@...e.de>
Cc:	Dave Jones <davej@...hat.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jörn Engel <joern@...fs.org>,
	David Brown <lkml@...idb.org>,
	Phil Oester <kernel@...uxace.com>,
	Kay Sievers <kay.sievers@...y.org>,
	Phillip Lougher <phillip@...gher.demon.co.uk>,
	Christoph Hellwig <hch@...radead.org>,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [GIT PULL] Squashfs pull request for 2.6.29

* Greg KH <gregkh@...e.de> wrote:

> > I don't mean to piss on your parade, but from my viewpoint, staging is 
> > a trainwreck so far, and I'd hate to see it get worse.
> 
> What is wrong with it?  Bugs are getting fixed, people are getting use 
> out of their hardware (hell, Linus is even using one of the drivers), 
> and lots of developers are cutting their teeth on helping out.
> 
> If you don't like it, just disable it in your kernel packages, or 
> instantly close out the bugs.  The drivers in staging has already helped 
> out some distros by virtue of including newer drivers than they were 
> mistakenly using at the time (Ubuntu, I'm looking at you...)
> 
> And again, it's helped out users, which is the most important thing 
> here.

yes.

Firstly, a distro can disable CONFIG_STAGING just fine and then there will 
be no 'crappy' drivers in that distro.

The thing is, the past decade has taught us that distros are willing to 
apply just about any crap if it helps out a significant proportion of 
users. Utrace crashes in Fedora dominated kerneloops.org stats for months. 
Special ACPI patches and hacks, experimental wireless and DRI drivers in 
Fedora, etc.

Why should the mainline kernel be any different? Treating it differently 
would be a double standard. If a distro can apply crappy patches in sake 
of utility, why shouldnt the upstream kernel have a staging area where 
useful but not fully upstream-worthy drivers can hang around?

For years the upstream kernel was a lot less useful to testers in practice 
because all the crappy but useful patches were in the distro kernels but 
not in the mainline kernel.

Now that the upstream kernel has such an area, exactly what has changed - 
besides making the kernel more useful, more testable, more hackable and 
more viable? In fact i claim that crap gets cleaned up much faster if it's 
out in the open for all to see - instead of hidden in distro SRPMs.

	Ingo
--
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/