Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751791AbaDWWf1 (ORCPT ); Wed, 23 Apr 2014 18:35:27 -0400 Received: from ozlabs.org ([103.22.144.67]:33226 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751348AbaDWWfZ (ORCPT ); Wed, 23 Apr 2014 18:35:25 -0400 Date: Thu, 24 Apr 2014 08:35:15 +1000 From: Stephen Rothwell To: Andrew Morton Cc: Davidlohr Bueso , "Michael Kerrisk (man-pages)" , Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups Message-Id: <20140424083515.b113760f062072e69d1899ac@canb.auug.org.au> In-Reply-To: <20140423152755.7f323cfd0e6901a2907afca8@linux-foundation.org> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> <53574AA5.1060205@gmail.com> <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> <20140423152755.7f323cfd0e6901a2907afca8@linux-foundation.org> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA256"; boundary="Signature=_Thu__24_Apr_2014_08_35_15_+1000_wcig3Jp=HffsP76." Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Signature=_Thu__24_Apr_2014_08_35_15_+1000_wcig3Jp=HffsP76. Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 23 Apr 2014 15:27:55 -0700 Andrew Morton wrote: > > On Tue, 22 Apr 2014 22:25:45 -0700 Davidlohr Bueso wro= te: >=20 > > On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote: > > > On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: > > > > - Breakup long function names/args. > > > > - Cleaup variable declaration. > > > > - s/current->mm/mm > > > >=20 > > > > Signed-off-by: Davidlohr Bueso > > > > --- > > > > ipc/shm.c | 40 +++++++++++++++++----------------------- > > > > 1 file changed, 17 insertions(+), 23 deletions(-) > > > >=20 > > > > diff --git a/ipc/shm.c b/ipc/shm.c > > > > index f000696..584d02e 100644 > > > > --- a/ipc/shm.c > > > > +++ b/ipc/shm.c > > > > @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_= vm_ops =3D { > > > > static int newseg(struct ipc_namespace *ns, struct ipc_params *par= ams) > > > > { > > > > key_t key =3D params->key; > > > > - int shmflg =3D params->flg; > > > > + int id, error, shmflg =3D params->flg; > > >=20 > > > It's largely a matter of taste (and I may be in a minority), and I kn= ow > > > there's certainly precedent in the kernel code, but I don't much like= the=20 > > > style of mixing variable declarations that have initializers, with ot= her > > > unrelated declarations (e.g., variables without initializers). What i= s=20 > > > the gain? One less line of text? That's (IMO) more than offset by the= =20 > > > small loss of readability. > >=20 > > Yes, it's taste. And yes, your in the minority, at least in many core > > kernel components and ipc. >=20 > I'm with Michael. >=20 > - Putting multiple definitions on the same line (whether or not they > are initialized there) makes it impossible to add little comments > documenting them. And we need more little comments documenting > locals. >=20 > - Having multiple definitions on the same line is maddening when the > time comes to resolve patch conflicts. And it increases the > likelihood of conflicts in the first place. >=20 > - It makes it much harder to *find* a definition. And it changes a line that has nothing to do with the patch. Sometimes the minority are right :-) --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au --Signature=_Thu__24_Apr_2014_08_35_15_+1000_wcig3Jp=HffsP76. Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJTWEApAAoJEMDTa8Ir7ZwVh5MP/AjyWRpF1vz5tM8Xy0uStunV +sWsjHOtwRV3FoSoVtFMFhrUVT3wGE4eBy8VIIdSPyk+sfUQ3JRRUCl49Sdy29A8 S2PMPZpqCFaKjNs0P/K+0lFIoq/GHROwFQsgyZtCmEpLGHP4Yc3mZGMwugbosy7I fpdJcYBG63GbHrkadTp7OnL5tKb604isrkGr1tDw9VYiOovlq/u3huXX8QAX/zqB Z65QBQy8R/CzAVD6I6VfVCXWwZ54obPbF3sjmq0IH7cjrY/wi9FB+LIDBPckyHR1 0ca0hDmSn0MB+OWAPeJJgrq7p0v3MjxQdzAcfiRznR/GKBlP1t7cYEiqDJl+DhaB D876joQXDoUqkxclT42LbR0vyCUy6SRMNPvXWZz/XrS6JA9Gssi2cgDgCu1NbvP5 p1MPZPXO4Tnk4iqFezp09U7QAY0gUat742b9dv8jyKozupYkEzpkduZfTei6S5kJ PZn0ykE32RAWNo2Js16thsfyYHXFEqjpv70l/MIfnjJ5BEidxYOz0GXmc/vDy/iq ixFXmTZhWeC+uPoudUf7fBzPLFcxs1M1HBxPhwFZw//A3Kq54Y5Ls+etPJ922s3j ftCgIEGgac/CiUbVLRogIYCfs2rzs29EvFZEyy/TPm627onH/yeAOcnuOrT/ClHG nXbrJfzMpgXzC5/plvbd =18lG -----END PGP SIGNATURE----- --Signature=_Thu__24_Apr_2014_08_35_15_+1000_wcig3Jp=HffsP76.-- -- 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/