linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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:	Fri, 28 May 2010 09:39:00 -0400
From:	tytso@....edu
To:	Igor Stoppa <igor.stoppa@...ia.com>
Cc:	ext Brian Swetland <swetland@...gle.com>,
	ext Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	"Balbi Felipe (Nokia-D/Helsinki)" <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Fri, May 28, 2010 at 04:32:15PM +0300, Igor Stoppa wrote:
> 
> What I consider plain wrong i to claim that since there are this
> many units out, some code should be merged.
> A company needs to cut corners sometimes when making a product but
> this should not affect upstream code.

Linus will disagree with you there.  Linus *has* merged code on the
basis that it is shipping in distributions, regardless of the fact
that some developers objected to it.  Sometimes "perfect" should not
be the enemy of "good enough" shipping code.

For example, I used to point out that we shipped PCMCIA code in
mainline that had a 10% chance of crashing the system if you ejected
the card.  NetBSD was proud to say that their code was so iron-clad
and well designed that it always did the right thing, even if you
ejected while it was busily passing network traffic.  Unfortunately,
NetBSD had working PCMCIA support 3 years later than Linux.  So it
used to be that we were the technical pragmatists (and Linus
fortunately, still very much is the pragmatists, while others were the
hard-line perfectionists.  It seems to me we've started getting some
of the NetBSD attitude infecting LKML, and IMHO, that's unfortunate.

We've rewritten our networking stack, 3 or 4 times, depending on how
you count.  And sometimes shipping in products counts for a lot.  It
doesn't count for everything, and it isn't a get-out-of-jail card, for
sure.  But if it's a hard problem, and we have something that's good
enough, maybe the right call is to merge it now, and we'll rework
things to make something better and more general later.  Ultimately
that's a call only Linus can make.

If everyone agrees we're making progress, and we can let this 100+
mail thread keep going.  But if anyone feels that we are spinning
endlessly without making forward progress (which is after all the same
criteria the OOM killer uses, no? :-), people should remember that
sometimes Linus *has* ended arguments that have gone on too long by
making a "merge or kill" decision.

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