From: Namhyung Kim <namhyung@gmail.com>
Subject: Re: [PATCH] ext3: Coding style fix in namei.c
Date: Fri, 19 Nov 2010 23:45:28 +0900
Message-ID: <1290177928.1678.51.camel@leonhard>
References: <1290161589-5370-1-git-send-email-namhyung@gmail.com>
	 <60024FF1-3903-49AD-9A68-B04C6D678A8E@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Jan Kara <jack@suse.cz>, Andrew Morton <akpm@linux-foundation.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
To: Theodore Tso <tytso@MIT.EDU>
In-Reply-To: <60024FF1-3903-49AD-9A68-B04C6D678A8E@mit.edu>
Sender: linux-ext4-owner@vger.kernel.org


2010-11-19 (=EA=B8=88), 07:57 -0500, Theodore Tso:
> On Nov 19, 2010, at 5:13 AM, Namhyung Kim wrote:
>=20
> > * break long lines (using temp variables if needed)
> > * merge short lines
> > * put open brace on the same line
> > * use C89-style comments
> > * remove a space between function name and parenthesis
> > * remove a space between '*' and pointer name
> > * add a space after ','
> > * other random whitespace fixes
> >=20
> > Signed-off-by: Namhyung Kim <namhyung@gmail.com>
>=20
> What's the benefit of such massive cleanup patches, really?   Does it
>  really enhance readability _that_ much?
>=20
> I believe in cleaning up code as I make substantive, useful change, b=
ut
>  code churn for code churn's sake has a number of downsides:
>=20
> *) It breaks other people's patches that might be pending (probably n=
ot
>  as much of an issue for ext3)
> *) It makes it really easy to introduce
>  security holes in code (although it looks like --- I haven't checked
>  to make sure --- this shouldn't change the compiled code any so we c=
an
>  at least audit this by applying the patch, and then checking to make
>  sure the .o hasn't changed.   What really makes my skin crawl is a
>  massive change like that which doesn't have zero impact on the
>  compiled object code.  If I get a patch like that, I reject it out o=
f
>  hand for ext4.)
>=20
> Bottom line is I really don't think cleanup code helps a lot.  It
>  wastes your time --- why not find some way of improving the kernel
>  that has more impact --- and it wastes the time of the responsible
>  maintainer (who has to go through the code with a fined-toothed comb
>  to make sure there's nothing bad hidden in a massive patch like this=
).
>=20
> Best regards,
>=20
> -- Ted
>=20

Hi Ted,

I wrote this patch because checkpatch complains about the code when I
tried to write another. Since I saw many codes in namei.c doesn't
conform the kernel coding style so I decided to write this coding style
patch first and others on top of it. But if you think it is totally
useless, I'm fine with dropping it.

BTW, I just checked that compiled code itself has no change on x86_64,
but there was a change in .rodata section.

Thanks.

--=20
Regards,
Namhyung Kim


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html