Date: Mon, 22 Jun 2009 11:44:08 -0700 (PDT)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Bernd Schmidt <bernds_cb1@t-online.de>
cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       Blackfin Architecture Team 
	<uclinux-dist-devel@blackfin.uclinux.org>,
       David Howells <dhowells@redhat.com>, stable@kernel.org
Subject: Re: Fix for shared flat binary format in 2.6.30
In-Reply-To: <4A3F5EAE.7020402@t-online.de>
Message-ID: <alpine.LFD.2.01.0906221137580.3240@localhost.localdomain>
References: <4A3F5EAE.7020402@t-online.de>
User-Agent: Alpine 2.01 (LFD 1184 2008-12-16)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1372
Lines: 34


On Mon, 22 Jun 2009, Bernd Schmidt wrote:
>
> This fixes a crash in 2.6.30 with shared flat binaries.  prepare_binfmt now
> requires a cred pointer to be set up, which isn't done in binfmt_flat.c.

This has so many bugs in patch submission that I literally almost gave up 
despite it being a trivial patch.

Attachements, wrong separators between explanation, wrong patch format 
(hint: use "-p1" or some sane patch system that gets things right 
_without_ crap), you name it. Very irritating.

I'm generally not interested in cleaning up after people who can't bother 
to try to make patches in the right format. If you can't bother to spend 
the small amount of time to make sure the patch is properly formatted, why 
should I bother to apply it?

It literally looks like you used SVN to generate that sh*t-for-brains 
patch. If you have to use svn, at least learn to make it generate proper 
patches.

(How? I don't know. Maybe "svn diff -p1" works? Why would _anybody_ ever 
use SVN for the kernel anyway? The "S" stands for "Substandard").

I applied this patch, but I want to just vent my frustration with it.

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/