[lkml]   [2001]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] reformat mtrr.c to conform to CodingStyle
On Tue, Nov 13, 2001 at 12:10:22PM -0700, Andreas Dilger wrote:
> On Nov 12, 2001 23:25 -0500, Benjamin LaHaise wrote:
> > Please incorporate this patch to make mtrr.c conform to the standards set
> > forth in Documentation/CodingStyle which make it much more appealing to
> > the eyes.
> >
> > /* Put the processor into a state where MTRRs can be safely set */
> > -static void set_mtrr_prepare (struct set_mtrr_context *ctxt)
> > +static void
> > +set_mtrr_prepare(struct set_mtrr_context *ctxt)
> > {
> Is that actually CodingStyle? Don't see it much in the kernel code...
> The much more common (AFAICS) style to split long function definitions is
> static void foo_long_function(struct long_struct name *foo, struct bar *bar,
> int val, long *err)
> The only reason (AFAICS) for putting the return type on a separate
> line is the (ancient) ansi2knr script, which just throws the return
> types away for pre-ANSI compilers. Given that the kernel code doesn't
> even conform to ANSI-C, there is no hope in hell of it compiling with
> a pre-ANSI compiler.

grep:ing for the function-name using ^fname is a common use. Easily
solvable anyway, but...

I don't think Lindent does everything 100% correct; at least its
formatting of switch/case does look a little fishy:

switch (option) {
case 1:
/* blaha */

That feels kind of odd compared to the rest of the codingstyle.


/David Weinehall
_ _
// David Weinehall <> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> </ Full colour fire </
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.094 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site