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: <Pine.LNX.4.58.0607211409540.27644@sbz-30.cs.Helsinki.FI>
Date:	Fri, 21 Jul 2006 14:20:02 +0300 (EEST)
From:	Pekka J Enberg <penberg@...Helsinki.FI>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
cc:	Panagiotis Issaris <takis@....org>,
	Jeff Garzik <jgarzik@...ox.com>,
	Rolf Eike Beer <eike-kernel@...tec.de>,
	Panagiotis Issaris <takis@...umba.uhasselt.be>,
	linux-kernel@...r.kernel.org, len.brown@...el.com,
	chas@....nrl.navy.mil, miquel@...uba.ar, kkeil@...e.de,
	benh@...nel.crashing.org, video4linux-list@...hat.com,
	rmk+mmc@....linux.org.uk, Neela.Kolli@...enio.com,
	vandrove@...cvut.cz, adaplas@....net, thomas@...ischhofer.net,
	weissg@...nna.at, philb@....org, linux-pcmcia@...ts.infradead.org,
	jkmaline@...hut.fi, paulus@...ba.org
Subject: Re: [PATCH] drivers: Conversions from kmalloc+memset tok(z|c)alloc.

At some point in time, I wrote:
> > There are things that are almost generally agreed upon, such as 
> > removal of redundant typecasts, redundant wrappers, and moving 
> > assignment out of if statement expression. Formatting and the dreaded
> > sizeof thing, however, are not, so it is best to keep them as-is.

On Fri, 21 Jul 2006, Stefan Richter wrote:
> Contributors can't know what the (supposed) _agreements_ are.
> 
> Contributors can only know what the _documented conventions_ are.

Life gets easier when you accept the fact that there are different 
conventions within the kernel, driven by maintainer preference. Which is 
why it is impossible to document a definite set of conventions too. 
CodingStyle really is just a good approximation what kernel code should 
look like. If you deviate from it too much, everyone agrees that 
you're violating it, but there definitely is room for maintainer 
preference. As a contributor, when you accept that, you'll have much 
greater chances of getting your patches merged.

				Pekka
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ