LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jan Engelhardt <jengelh@computergmbh.de>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>,
	"Kok, Auke" <auke-jan.h.kok@intel.com>,
	Randy Dunlap <randy.dunlap@oracle.com>,
	Chris Friesen <cfriesen@nortel.com>,
	dave young <hidave.darkstar@gmail.com>, Willy Tarreau <w@1wt.eu>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: coding style
Date: Sat, 16 Jun 2007 08:49:55 -0700 (PDT)
Message-ID: <alpine.LFD.0.98.0706160840290.14121@woody.linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0706160833220.32724@fbirervta.pbzchgretzou.qr>



On Sat, 16 Jun 2007, Jan Engelhardt wrote:
> >
> >Heh. Actually, Linux maintainers have generally very consciously _avoided_ 
> >trying to "enforce" coding style issues.
> 
> Really? "it's not going to be merged unless you turn all uint32_t into
> u_int32_t" is a paraphrased variant of what I was told this month.

I suspect different maintainers are hung up on different things, so yes, 
certain things are more likely to carry red flags, and it also depends on 
the patch.

For example, if I get a patch for something that is a whole driver, I 
generally think that while I *prefer* to see it follow the kernel coding 
style, I also expect that the person who sends me the driver is the one 
who is going to maintain it in the future, and thus his personal coding 
style preferences will override any but the strongest objections.

(So if somebody sends me a FSF-style "tabs are two characters, and 
functions must be longer than 300 lines" mess, I generally would prefer to 
not take it at all, but for some really obscure driver I might not care).

In contrast, if a patch modifies code that somebody else really will end 
up touching in the future (maybe not "maintain", but maybe there is no 
single and obvious maintainer), it had better match the code around it.

So to take your particular example: For me, "uint32_t" is certainly better 
than "u_int32_t" (and there's seven times as many of the former as the 
latter in the kernel), but for code _I_ would touch, I'd actually prefer 
the Linux internal "__u32"/"u32", which have no question about what their 
user-space visibility is (ie "__u32" is *always* ok in a header file that 
is visible to user space).

But would I make it a huge issue? Not personally. So it will depend on the 
maintainer.

(Personally, I think the "small functions, no deep levels of indentation, 
and tabs are 8 characters wide" are the most important part by far. But I 
do actually end up complaining about function naming etc too).

		Linus

  parent reply index

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-14 18:48 Cyrill Gorcunov
2007-06-15  4:51 ` Willy Tarreau
2007-06-15  5:09   ` Kok, Auke
2007-06-15  6:38     ` dave young
2007-06-15  6:47       ` debian developer
2007-06-15  6:54         ` dave young
2007-06-15  9:06         ` Mailing style (was Re: coding style) Bernd Petrovitsch
2007-06-15  9:19           ` debian developer
2007-06-15  9:16       ` coding style Jan Engelhardt
2007-06-15 17:32         ` Cyrill Gorcunov
2007-06-15 17:54           ` Chris Friesen
2007-06-15 18:03             ` Randy Dunlap
2007-06-15 19:10               ` Jan Engelhardt
2007-06-15 19:18                 ` Cyrill Gorcunov
2007-06-15 19:21                   ` Kok, Auke
2007-06-15 19:29                     ` Cyrill Gorcunov
2007-06-15 19:31                     ` Jan Engelhardt
2007-06-15 19:41                       ` Cyrill Gorcunov
2007-06-15 20:21                         ` Linus Torvalds
2007-06-15 20:35                           ` Jan Engelhardt
2007-06-16 12:30                             ` Stefan Richter
2007-06-15 20:21                         ` Jan Engelhardt
2007-06-15 20:39                           ` Linus Torvalds
2007-06-16  6:38                             ` Jan Engelhardt
2007-06-16 12:40                               ` Stefan Richter
2007-06-16 15:49                               ` Linus Torvalds [this message]
2007-06-19 14:05                                 ` Mark Lord
2007-06-15 19:45                       ` Kok, Auke
2007-06-15 19:49                         ` Cyrill Gorcunov
2007-06-15 20:28                         ` Jan Engelhardt
2007-06-15 22:10                   ` Randy Dunlap
2007-06-16 12:59                     ` please keep the CodingStyle text in check (was Re: coding style) Stefan Richter
2007-06-15 18:05             ` coding style Kok, Auke
2007-06-15 18:22               ` Cyrill Gorcunov
2007-06-16 13:07                 ` Stefan Richter
2007-06-16 14:31                   ` gorcunov
2007-06-16 17:43                     ` Stefan Richter
2007-06-16 18:22                       ` Cyrill Gorcunov
2007-06-16 14:22         ` Clifford Wolf
2007-06-15  8:56     ` Krzysztof Halasa
  -- strict thread matches above, loose matches on Subject: below --
2001-01-23 15:07 Coding Style Jonathan Earle
2001-01-24  3:23 ` john slee
     [not found] <Pine.LNX.4.10.10101192217390.9361-100000@penguin.transmeta .com>
     [not found] ` <3A68E309.2540A5E1@purplecoder.com>
2001-01-20  6:29   ` Linus Torvalds
2001-01-20 15:32   ` Anton Altaparmakov
2001-01-21  8:24     ` george anzinger
2001-01-19 17:59 Mark I Manning IV
2001-01-20  0:09 ` David Ford
2001-01-20  1:26   ` John Cavan
2001-01-20  0:46 ` Albert D. Cahalan
2001-01-20  5:34   ` Linus Torvalds
2001-01-21  2:00 ` Matthias Andree
2001-01-22  8:24   ` Ralf Baechle
2001-01-22 22:28     ` Mark I Manning IV
2001-01-23  3:56       ` adrian
2001-01-23 20:05 ` Boris Dragovic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.0.98.0706160840290.14121@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=auke-jan.h.kok@intel.com \
    --cc=cfriesen@nortel.com \
    --cc=gorcunov@gmail.com \
    --cc=hidave.darkstar@gmail.com \
    --cc=jengelh@computergmbh.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.com \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git
	git clone --mirror https://lore.kernel.org/lkml/10 lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git