linux-kernel - Re: [PATCH 2/2] FRV: Move to arch/frv/include/asm/

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:	Thu, 9 Apr 2009 11:26:49 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...IV.linux.org.uk>
cc:	David Howells <dhowells@...hat.com>, akpm@...ux-foundation.org,
	sam@...nborg.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] FRV: Move to arch/frv/include/asm/

On Thu, 9 Apr 2009, Al Viro wrote:
> 
> We can teach patch(1) to handle those - apparently agruen has resurrected
> development lately (git://git.savannah.gnu.org/patch.git), so it might
> be possible without usual latency problems...

I think a lot of SCM's parse diffs internally, so people are still going 
to have to live with legacy patches.

The reason for doing diff parsing internally is that it's much easier to 
handle the error cases, or even just see what files were modified 
successfully.

If you executee an external "patch" command, it's really quite nasty to 
parse the whole "what happened" stuff both for the "everything applied 
fine" _and_ for the "oops, the patch failed in the middle" case. 

Doing diff parsing and application is also generally quite easy - at least 
compared to _generating_ them. In many ways it's easier to just handle the 
diff yourself than it is to try to parse the end result of running "patch" 
externally.

So I would not be at all surprised if many SCM's use an external "diff" to 
generate patches (that has none of the complexities of the error cases), 
but don't use an external "patch" to apply them.

			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/