linux-kernel - Re: [PATCH 3/5] x86: coding style fixes in arch/x86/ia32/ia32

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: <20080108215247.GE14829@elte.hu>
Date:	Tue, 8 Jan 2008 22:52:47 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Rik van Riel <riel@...hat.com>
Cc:	Paolo Ciarrocchi <paolo.ciarrocchi@...il.com>, tglx@...utronix.de,
	mingo@...hat.com, hpa@...or.com,
	Linux Kernel <linux-kernel@...r.kernel.org>, trivial@...nel.org
Subject: Re: [PATCH 3/5] x86: coding style fixes in
	arch/x86/ia32/ia32_aout.c

* Rik van Riel <riel@...hat.com> wrote:

> On Tue, 8 Jan 2008 20:32:33 +0100
> Paolo Ciarrocchi <paolo.ciarrocchi@...il.com> wrote:
> 
> > Fix plenty of coding style errors
> 
> Most of these kernel changes would probably get in the way of real 
> development, making patches reject that would otherwise apply.

I'm curious, in what way would they interfere?

Firstly, anyone with a forked kernel with outstanding patches that are 
not in x86.git only has themselves to blame. We want to actively 
discourage forking and sitting on patches too long.

Secondly, when there _is_ some non-trivial interaction with reasonably 
recently-developed patches, the solution is simple and straightforward 
we simply undo the relevant portions of the cleanup, apply the 
functional patch and later on apply the (still relevant) cleanup patches 
to around the functional patch.

Since all new x86.git patches are checkpatch.pl clean, the modified 
portions need no cleanups anymore - only unmodified portions.

How many times did we have to do this in x86.git? Once or twice - out of 
100+ cleanup patches.

In reality, rarely do cleanup patches interfere. They have two positive 
effects besides the obvious readability, debuggability and 
maintainability advantages:

- they _do_ cause people to come out of their distro-patched
  fork-woodwork and submit their "development" patches (which were "in
  the works" for ... years).

- the cleanups make future development _easier_, because it's easier to
  develop on a clean codebase.

and because the number of future patches is infinitely larger than the 
number of still pending but not submitted development patches, we 
strongly favor cleanups.

so in the end it all works out fine.

	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/