linux-kernel - Re: [PATCH] 0/3 coding standards documentation/code updates

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] [day] [month] [year] [list]

Message-Id: <20070930105930.1b330c84.randy.dunlap@oracle.com>
Date:	Sun, 30 Sep 2007 10:59:30 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Mark Lord <lkml@....ca>
Cc:	Erez Zadok <ezk@...sunysb.edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] 0/3 coding standards documentation/code updates

On Sun, 30 Sep 2007 13:40:13 -0400 Mark Lord wrote:

> Erez Zadok wrote:
> > In message <alpine.LFD.0.999.0709291748160.3579@...dy.linux-foundation.org>, Linus Torvalds writes:
> >>
> >> On Sat, 29 Sep 2007, Erez Zadok wrote:
> >>> Would you prefer if CodingStyle was reorganized or even split into (1)
> >>> general principles and (2) details?  Perhaps we need a CodingStylePrinciples
> >>> and a CodingStyleDetails?
> >> I'm certainly ok with the split into two files.
> >>
> >> What I'm not ok with is really important stuff (indentation), and then 
> >> mixing in silly rules ("parenthesis are bad in printk's"?)
> >>
> >> 		Linus
> > 
> > OK, looking at CodingStyle, I see two kinds of chapters.  The first is stuff
> > that's more generic to C, and the other is more specific to Linux and how
> > one codes in the linux kernel.  So I propose the following:
> > 
> > 1. we create a new file called CodingSuggestions
> > 
> > 2. we keep in CodingStyle the following chapters
> > 
> >    Chapter 1: Indentation
> >    Chapter 2: Breaking long lines and strings
> >    Chapter 3: Placing Braces and Spaces
> >    Chapter 4: Naming
> >    Chapter 5: Typedefs
> >    Chapter 6: Functions
> >    Chapter 7: Centralized exiting of functions
> >    Chapter 8: Commenting
> >    Chapter 9: You've made a mess of it
> > 
> >    Note: I'd suggest we rename the title of ch9 to "Custom Editor
> >    Programming/Indentation Modes" or something more descriptive.
> > 
> >    Chapter 10: Kconfig configuration files
> >    Chapter 11: Data structures
> >    Chapter 12: Macros, Enums and RTL
> >    Chapter 15: The inline disease
> >    Chapter 16: Function return values and names
> >    Chapter 18: Editor modelines and other cruft
> > 
> > 3. move the following chapters to CodingSuggestions:
> > 
> >    Chapter 13: Printing kernel messages
> >    Note: ch13 is the one which mentions the don't put parentheses around %d.
> > 
> >    Chapter 14: Allocating memory
> >    Chapter 17: Don't re-invent the kernel macros
> >    Chapter 19: branch prediction optimizations (the un/likely debacle)
> 
> Super.  And then, in the spirit of Linus's request,
> we can submit another patch that simply removes that second file
> completely from the kernel source tree!

or just revert CodingStyle to its contents of say 4 years ago.

> Yay!  The suits actually lose for once!
> (okay, so I can fantasize if I want to).

Yep, you can.

The other losers are new contributors who get rejected for not
understanding implicit kernel coding styles and people who
get to try to explain to them on a repeating basis (if even
that happens).

or the kernel maintainers if coding style doesn't matter so much
and uglier code begins to be merged.

---
~Randy
-
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/